DDD: Trying to code sorting and filtering as it pertains to Poco, Repository, DTO, and DAO using C#?

I get a list of items from my Repository. Now I need to sort and filter them, which I believe would be done in the Repository for efficiency. I think there would be two ways of doing this in a DDD way:

1. Send a filter and a sort object full of conditions to the Repository (What is this called)?
2. Repository result would p开发者_如何学JAVAroduce an object with .filter and .sort methods? (This wouldn't be a POJO/POCO because it contains more than one object?).

So is the answer 1, 2, or other? Could you explain why? I am leaning toward #1 because the Repository would be able to only send the data I want (or will #2 be able to delay accessing data like a LazyList?) A code example (or website link) would be very helpful.

Example:

1. Product product = repo.GetProducts(mySortObject, myFilterObject); // List of Poco
2. product.AddFilter("price", "lessThan", "3.99"); product.AddSort("price", "descending");

I would personally go with your first option.

If you think about the second option from a DDD perspective the product object, which I'm assuming is your domain object, has a knowledge about something that isn't really part of the business problem you are trying to solve (I.E., you domain). Rather sorting and filtering is used in the user interface or some other back end processing component.

Additionally when looking at the second option from a Single Responsibility (aka SOLID) perspective you'll see that your Product business object has the responsibility for sorting and filtering, something that isn't at all related to a product.

That's how I see things. I would be interested in others opinions.

This isn't a complete answer, but you might want to take a look at some of the thinking behind CQRS (Command Query Responsibility Segregation) (some good links can be found here).

CQRS is a way of thinking about DDD that can help clarify some of this. It's at a higher level than your specific question, but it might help.

Essentially I think it will just help you decide to go with your first option (which is what I ended up with in a similar situation). We called it a Query Object.