Are both options correct? Is one of them better than the other? Under what situations? Is one harder to achieve than the other?
views:
120answers:
2Ideally 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.
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).