3

I have a question about what to do with a entity that is not a representation of the data in the database, but a custom made entity that I need for business purposes.

My solution is structured in:

  • Entities assembly (POCO objects)
  • Repository assembly (EF Code First)
  • Business layer assembly
  • UI Assembly (MVC)

In my entities assembly I have two entities, A and B, and for a specific purpose of my business logic, I need to return an object that contains both (among other properties):

class X
{
   public A[];
   public B[];
}

Should I return this object directly from the repository? Or should the business layer call to repo.GetA and repo.GetB and then create X and return it?

In this case, maybe it makes sense to create the object in the business layer. But what if the X class was a "group by" of A and B? then returning it from the repository makes more sense.

I guess there is no silver bullet, but are there any guidelines?

Cheers.

vtortola
  • 34,709
  • 29
  • 161
  • 263
  • To follow true DDD I think that your Entities and Repository interfaces should all be in the Business (Domain) Layer. – Meta-Knight Jan 09 '13 at 14:18

2 Answers2

4

I think you need to figure out which layer X belongs to and what it really is :

  • A domain entity, i.e. it conveys a domain concept from the ubiquitous language. In that case, X is probably an aggregate root that contains a list of A and B child entities. It may also have methods in addition to data. X's repository would persist the A and B collections along with X objects, and there would be no repository for A or B.

  • A UI specific or use case specific data structure. In which case the domain layer has no business with X. The application or UI layer will take care of doing the mapping between A and B instances and the X object.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • And what happens if it is UI specific, but it is very expensive to create it out of the repository? E.g.: an entity result of a join/grouping of several tables? – vtortola Jan 09 '13 at 22:59
  • You can have specialized "analytical" repositories besides the normal repositories. Similar problems are discussed here : http://stackoverflow.com/questions/2098112/ddd-how-to-implement-high-performing-repositories-for-searching, http://stackoverflow.com/questions/2558469/ddd-aggregate-roots – guillaume31 Jan 10 '13 at 09:41
2

My understanding is that the repository should always deal with business-type objects. For you this would be equivalent to a repository returning objects of type X. How X is created is the repository's business. This could be via 2 data mappers getting A and then B and merging the results or some other, appropriate, process.

David Osborne
  • 6,436
  • 1
  • 21
  • 35