Interesting use!

for example if apply the Dao, then the client (caller) need to understand and learn some complicated detail or Dao objects.

the codes should looks like:

Client c=new Client(clientDao).

if you do others, you also have to know the related Daos for those entities.

but for Repository.

the repository just apply for root entity for an aggregate.

so there are more less repository need to learn or even you can apply repository factory pattern.

codes looks like:

Client c=new Client(RepositoryFactory.getInstance())

within the Client:

Client(factory){
repository=factory.getRepository(Client.class);
}

hope can help you a little.

The discussion here shows one thing very clearly: who says, the decision that ‘getOrders’ is connected to ‘Client’ is a good decision? Sometimes when starting the project the requirements are not known completely. At least while developing web application where requirements can change very often, it seems to me a better approach to maintain a stable domain model (which we do in our case in the Tiny Marbles repository), and delegate the business logic to ‘services’ (in our case using the Command pattern) which changes the state of the repository, or simply gives filtered information about the current state of the system. For the example you mentioned in your post we would prefer: getRepo.OrdersSinceDate(User, date). And we even go one step further: we are using the object ‘User’ with the role ‘customer’ or ‘client’.

@Fabio: I would love to discuss our philosophy with you, although I know, you don’t agree and this place might not the right board for that. But hopefully some day there will be an opportunity

Peace
-stephan

You are just kidding, right?