Question

My domain entities are lined up like a tree:

Root
– Child 1
— Child 1.1
— Child 1.2
– Child 2
— Child 2.1
— Child 2.2

We ended up with 2 (rather strong) opinions on how a repository should be designed around these domain objects:

Opinion 1:
I need 2 repositories Child1Repository & Child2Repository which gets managed by a RootFacade/RootManager class to call the appropriate method on the repository. The 2 child repositories handle only the DAL operations while the RootFacade is the BLL. The RootFacade exposes DTO’s to the application while internally all the 3 repositories use domain objects

Opinion 2:
I need 1 repository RootRepository which handles everything (BLL + DAL). The repository exposes DTO’s while internally it works with the domain objects

I would like to have some perspective on these 2 points & which is really the way to go about for a repository implementation.

Thanks for all the help

Answer 1

Classes shouldn’t take on more responsibility than they need to, and it definitely sounds like the approach of a RootRepository is the wrong way to go here. It absorbs too much complexity and is responsible for too many entities. Of the two options you presented, the first is the better choice: have more repositories that are each responsible for their own corner of your domain.

However, that said, it’s not clear to me why you have a RootManager at all. I would much rather have a series of DomainObjectRepositories which each managed their own business logic internally, and only exposed the relevant public operations, then defer actual database operations to a data-access object DomainObjectDao. Having an omniscient all-the-biz-logic class is a monstrous code smell, and smacks of enterprisey overkill in this particular case.