1

in the book dependency injection in .net (a great book thanks mark). in page 41 MISCELLANEOUS OTHER ISSUES : he speaks about one anti pattern, ui that reference DAL and BLL, DAL that defines Domain Objects (entity framework autogenerated objects) he says :

Most of the Domain Model seems to be implemented in the Data Access library. Whereas it’s a technical problem that the Domain Model library references the Data Access library, it’s a conceptual problem that the Data Access library defines such a class as the Product class. A public Product class belongs in the Domain Model.

i do understand that DAL must not define domain objects.but I don't understand why DML reference DAL is a technical problem? Are we talking about the BLL(business logic layer) when he speaks about Domain Model Library.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
riadh gomri
  • 869
  • 1
  • 15
  • 21
  • 1
    Most of the answer is here: http://stackoverflow.com/a/9503612/126014 – Mark Seemann Mar 13 '13 at 17:39
  • thanks Mark, so if i understand : +There is a dependency : if an object instantiate another object. +There is no dependency : if an object expects an abstraction (contructor injection, method injection ...) +Assembly References (referencing dll, webservices..) are independant from the dependency concept, because to resolve an abstraction and be able to compile the code, the layer must reference it. – riadh gomri Mar 14 '13 at 16:48

1 Answers1

4

Yes, Domain Model Library (DML) is a Business Logic Layer (BLL). This library should contain domain model entities (which should be persistent ignorant) and domain services.

Why that is a technical problem? Any changes in DAL will require compilation of DML. If you will inverse dependency, then DAL will act as a plugin for you domain. You will be free to change it (persist data in memory, file, or use other db provider) without affecting BLL.

Sergey Berezovskiy
  • 232,247
  • 41
  • 429
  • 459
  • So by reference, he means direct reference (tightly coupled)? Because if i am not wrong, in an n-tier architecture, every layer must referrence the layer under. – riadh gomri Mar 13 '13 at 14:37
  • 2
    @riadh yes, I think he means direct reference (like adding assembly reference). Also there are architectures where direction of dependencies is not from top to bottom, e.g. Onion (or Hexagonal) architecture - it has domain model in the center, which is referenced by persistence and presentation libraries. – Sergey Berezovskiy Mar 13 '13 at 14:44
  • 2
    @riadh The correct definition of n-*layer* architecture is that every layer must *communicate* with the layer beneath it. The architecture doesn't say anything about the direction of assembly references. – Mark Seemann Mar 13 '13 at 17:42
  • @lazyberezovsky so the question is where to put the shared Contracts (abstractions Interfaces or abstract classes) ? In a separate assembly ? a seperate assembly for each layer? Which is the best practice? – riadh gomri Mar 14 '13 at 16:54