I get the power of O/R mapping, and I get the power of abstracting the interface to the O/R mapper. After reading as much as I can about the DAO pattern, I get the benefit of it -- not only abstract access to an O/R tool, but abstract access to any DataSource.

So it seems that the pattern is to create DAO's that have very explicit, fine-grained methods (findPerson(), findCompany(), saveCompany(), etc) that maps to a specific Business segment.

I have worked on previous projects with an O/R mapper where we abstracted that interface in a generic layer with very loose methods for persistence: findObjectByCriteria(), findCollectionByCriteria(), etc. These methods worked well because we had a standard, generic way to access all of the Domain objects from our Business Logic, but the Business Logic knew it was getting it from a Database.

So I am conflicted: it seems like it is recommended to make your find methods explicit to what you are looking for, as to allow an interface to be defined for it. But I really don't want to maintain permutations for all possibilities. I guess I could create a PersistenceDAO that would have my generic logic to retrieved data from the DB passing in a Critieria object, but if I understand correctly, that breaks the pattern because I have now tied my Business Logic to the fact that it gets it's data from a DB, correct?

For people that use DAO's, how specific do you make your find methods? Does the DAO only contain logic to get that data, and no other business logic (validation, etc)? Do you find this tedious?

It's up to you, no-one can tell you which one to choose. I personally prefer typed DAOs, but the detyped approach could also work.

Personally, I don't think the code to set up a Criteria query belongs outside the DAOs.

In my projects I have done the following for DAOs.

Create a DAO per object which extends an interface with the following abstract methods.

public Object searchByPrimaryKey(Long id)
public List search (Object object)
public boolean saveOrUpdate(Object object)
public boolean delete(Object object)
public long saveMultiple(List objectList)
public long deleteMultiple(List objectList)

If I have to search by criteria, I populate the Object in the search() method with the necessary parameters and create the HQL within the method based on the parameters available. This has worked well for me in the past. Previously, in JDBC based DAOs I had methods that did searchByCriteria() etc and it created a major cluster with every developer having his own interpretation of it.

I like that idea, especially the search method (a quasi-findByExample). Now, in your implementation for that method, did you explicitly look to see if each and every property was set, or did you create some sort of HQL generator based upon an object and what property was set (not-null)?

I'd recommend using the criteria query example API for QBE

Squeak,

I'm facing the exact problem you are, as I really love using a generic dao with criterias. The previous O/R mapper I used the criteria object was very generic and just described a POJO. So the criteria object was well suited for use outside a DAO as it didn't depend on the OR mapper. The criterion in hibernate is dependent on the Session. This makes it very difficult (or at the least bad design as Gavin stated) to use the criteria anywhere but in a DAO. What did you end up doing? Thanks.

I'd write my own small Criteria wrapper with just the functionality I need. This is easier than it sounds. Together with QBE, this is good enough for most projects.

What's the benefit of extending a common interface for DAOs, compared to for example

class UserDAO {
public User searchByPrimaryKey(Long id) { ..}
public boolean saveOrUpdate(User user) { ... }
...
}

sure you get all methods named properly, but you end up doing casts in your code much more often. Or is there "real world" use for this kind of behaviour:

while (i.hasNext()) {
DAO unknownType = (DAO) i.next();
unknownType.delete(unknownType);
}

Not to say I have anything against your approach, I am just curious about how it works in practise.

why would u end up doing casts? the object type definitions are generic enough to allow for almost anything. i have a DAO.java interface with the above mentioned methods then implementations such as:

UserDAO.java
import my.user.class;
import java.util.ArrayList;

public class UserDAO implements DAO{
...
public ArrayList search(User user){ ... }
...
}

BlogEntryDAO.java
import my.blogentry.class;
import java.util.ArrayList;

public class BlogEntryDAO implements DAO{
...
public ArrayList search(BlogEntry blogEntry){ ... }
...
}

i dont see the need for any type casting....?

Well, let's say your Action (or whatever) updates one blog entry, you need:

BlogEntry entry = (BlogEntry) blogDAO.searchByPrimaryKey(blogId);

instead of

BlogEntry entry = blogDAO.searchByPrimaryKey(blogId);

Same for insert (which I usually implement so that it returns the object, now also with the primary key field that was not known before the insert). And, don't you need to implement DAO method like

public ArrayList search(Object blogEntry){
BlogEntry casted = (BlogEntry) blogEntry;
...
}

because otherwise you will be creating a new method instead of overloading the one from superclass?


Granted, that's not a huge inconvenicence. I guess I was more curious about what are the practical benefits?

yes you're right. it wouldnt overload the methods from the interface.