Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my application, I have a listing of information that is deducted from a query that combines information from several entities. In itself, a very common situation.

Now, the corresponding repository method should return a list that contains items of an appropriate type. Clearly, choosing an entity is not appropriate because the information we're dealing with spans across multiple entities. I guess the same applies when querying partial entities. Creating a new entity doesn't make sense either because it would only muddle the model.

I was thinking in the direction of something like creating a DTO in the application layer because the particular query really is there to satisfy an application requirement and not a business requirement.

This essentially leads to introducing the notion of application specific repositories and a dependency on the application layer from those specific repositories.

Somehow this doesn't feel right. Is there a more appropriate approach/pattern I could use here?

share|improve this question
up vote 8 down vote accepted

IS this a read-only situation? Because that's what it sounds like.

If you're doing DDD, then whenever you need to update/create something in your app you're going to go through the domain model because that is going to contain all of your business logic and validation.

However, there are times in your application when you just want to aggregate together a bunch of data to display to a user in a read-only fashion. In this case, exposing that data through a DTO via a service layer seems perfectly acceptible to me.

I wouldn't do it in the application layer though. I'd expose it as a service facade around my repositories. Let the facade deal with calling the respositories, aggregating the data and generating the DTO. From the application's point of view, it's just getting data with a call to a service. Nothing fancy.

share|improve this answer
+1 for facading via the service, keeping data access useful but isolated is key. – Wyatt Barnett Mar 31 '11 at 21:21
The separation of queries from the domain can be considered command-query responsibility segregation (CQRS). Though in this case I wouldn't expect you to apply CQRS across your codebase, but simply separate this query out from your domain. You can use a service, or more commonly a query object, which as Chris said would wrap the repositories involved. It may also be worth considering bypassing the repositories and going straight to the data source, if this is a performance critical area and your repositories are heavy. – quentin-starin Mar 31 '11 at 22:21
What if the query depends on a lot of business logic to filter out the data? – andho Jul 17 '11 at 15:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.