views:

120

answers:

2

Are both options correct? Is one of them better than the other? Under what situations? Is one harder to achieve than the other?

+1  A: 

Ideally neither should depend on the other - but practically the domain will depend on the data layer, but hopefully indirectly.

What does that mean?

The data layer defiantly should not depend on the domain layer.

The domain layer will likely make use of data objects, but ideally you'd do this through dependency injection. One way to do this is to use interfaces and only reference the interfaces at compile time. At runtime provide a concrete implementation for these interfaces through a IoC container such as Structure Map or Unity.

This will also help you be able to unit test your solution, as well as enforce separation of concerns and create a loosely coupled system.

Michael Shimmins
What types do you use in the interfaces? DAOs or domain entities? `void Save(ProductDAO p);` or `void Save(Product p);`? This will surely force one to depend on another. If the former, the domain layer needs to know about DAOs. What about fully encapsulated domains?
Martinho Fernandes
This approach has worked well for me. I define the DAO interfaces in the domain layer and pass domain objects to and from the interface methods. The domain entities reference the interfaces. Then at runtime I use a factory to instantiate the implementations of the DAOs. So the data access layer references the domain layer, but the domain objects reference only the DAO interfaces and are independent of the actual implementation.
BenV
A: 

Generally the domain (business logic) layer should depend on the data layer but not the other way round.

Rationale:

  • You want to maintain flexibility to alter business logic without having any unnecessary impact on data
  • The data layer will be much simpler and less error prone if you can design it to be independent of business logic decisions
  • The domain layer is generally the caller of the data layer so there is no need to make a dependency the other way round

This is actually quite analogous to the way that the domain layer should have minimal dependencies on the presentation layer (although in practice this can be difficult to achieve).

mikera