Routine to check record duplication in DAO pattern

Setya · **Posted:** Wed Jul 19, 2006 10:45 pm

Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hi all,

I've just read HIA, after finishing Chapter 8. (Writing Hibernate Applications) I have a question here.

Before persisting a domain model to DB I need to make sure that the record does not exist yet in the database by comparing ID from domain model to the one in DB.

That is, I need to query the DB first using the ID contained in the domain model and if the query returns 1 record that means the record already exists in the DB and the domain model should not be persisted.

I don't know where the above routine should take place, I definitely can not put it in the domain model itself since this will pollute the domain model with persistence API and DAOs.

Regards,

Setya

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

That belongs in business logic. If you have layers of business logic, it belongs in the lowest layer. If your DAO contains business logic code, that's a good place to put it. So your DAO might have a saveDomainModelInternal method that unconditionally saves the object (and thus throws an exception if the domain model already exists in the DB), a verifyDomainModelNotInDB method, and a saveDomainModel method like this

Code:

public void saveDomanModel(DomainModel md)
{
  if (verifyDomainModelNotInDB(dm))
    saveDomainModelInternal(dm);
}

Alternatively, you might choose to merge() or replicate() instead of save(), so that the in-memory domain model is written to the DB.

Setya · **Posted:** Thu Jul 20, 2006 1:11 am

Thanks for your response,

Quote:

That belongs in business logic. If you have layers of business logic, it belongs in the lowest layer. If your DAO contains business logic code, that's a good place to put it. So your DAO might have a saveDomainModelInternal method that unconditionally saves the object (and thus throws an exception if the domain model already exists in the DB), a verifyDomainModelNotInDB method, and a saveDomainModel method like this
public void saveDomanModel(DomainModel md)
{
if (verifyDomainModelNotInDB(dm))
saveDomainModelInternal(dm);
}
Alternatively, you might choose to merge() or replicate() instead of save(), so that the in-memory domain model is written to the DB.

HIA also states that DAO should not contain any business logic routines, it should only contain data access routine.

Regards,

Setya

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

And that's correct. However, this sort of simple logic, which is somewhere between business logic and DAO logic, sometimes bends that rule a little. It's not really business logic, it's just a convenience method in data access logic to avoid making data access that you know will fail. You can put it in business logic if that's suitable, or in DAO if it's better there.

Besides, it's your code. You don't have to adhere to every rule there is, just try to follow the best practices guidelines.