Reputation: 35963
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:
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.
Upvotes: 3
Views: 604
Reputation: 14080
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.
Upvotes: 4
Reputation: 6821
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.
Upvotes: 2