Christian said:The DAO interface for a particular entity, that's ok 
but can sometimes think in term of package.

Just one word about granularity, for big projects based on more than 
100 persistent classes, if your design is well done, you'll have 
different packages of 10-30 classes for example.

Use cases should be "driven" by a root entity for each package, so you 
can define one DAO interface per package.

Example: what if you have Order * -- 1 Client and you need to get the 
orders of a particular client? One use case needs only the orders, one 
other also need the client to be fetched. Do you code this in 
ClientDAO or OrderDAO knowing that client is the best candidate to be 
a root entity... 
This one is very simple but think about complex HQL queries on a 4 or 
6 levels object graph. The code is not so easy to add and if you have 
a big development team, there is risk to duplicate the code.

But you need to be carefull when designing your packages...