ORM tools in domain driven design?
-
Good day! I am a student and I am doing a study on Object Relation Mapping tools and how they fit into various software design patterns and approaches. For now I have tried some tools and read about their weaknesses and strengths related to ModelViewController and n-tier design patterns and also have an experience with some projects. But lately I have found out about domain-driven design (which involves also a model-driven design at some point because domain objects together make a domain model). And I got a bit confused how does this all fit together with ORM and what is ORM role in those designs. I have found this good article about practical example how to use MVC and domain driven design with Zend and PHP: angryobjects.com/2009/03/30/writing-robust-php-backends-with-zend-framework/comment-page-1/#comment-1201 The author suggests keeping the domain model completely clean and unaware of underlying persistence. Only some ServiceLayer is needed to convert domain objects to/from persistence objects and as I understood this involves also CRUD operations. But I want to know what happens if we introduce some ORM into this scenario. As I understand, the right way is to create domain model first and only after that think about how this model will be persisted with or without ORM. Let’s say, we have designed some domain model and now want to use ORM tool for easier persistence. ORM tool lets us generate some entity model and it is just logical that we’ll try to match this entity model with our domain model as closely as possible. But then we get some kind of duplication! We have a domain model with business logic in it and we have the same domain entities but with CRUD or various persistence attributes (maybe not visible but inherited from some base-class or interface). Then the question is - how good or bad idea is to merge our domain model with the ORM generated entities? When is it acceptable and allows us to say that we still have a good domain – driven design and when it is not acceptable because of too much “persistence aware” domain? Is it some trade-off thing going on here (clean domain entities versus duplicated entities)? I found this article: ibm.com/developerworks/java/library/j-pop1/ where they use some base classes and interfaces to implement common functionality in the domain model. But still the model entities contain some persistence awareness because of that inheritance. How good or bad is it from the point of view of clean domain model? Also the same problem arises when we try t
-
Good day! I am a student and I am doing a study on Object Relation Mapping tools and how they fit into various software design patterns and approaches. For now I have tried some tools and read about their weaknesses and strengths related to ModelViewController and n-tier design patterns and also have an experience with some projects. But lately I have found out about domain-driven design (which involves also a model-driven design at some point because domain objects together make a domain model). And I got a bit confused how does this all fit together with ORM and what is ORM role in those designs. I have found this good article about practical example how to use MVC and domain driven design with Zend and PHP: angryobjects.com/2009/03/30/writing-robust-php-backends-with-zend-framework/comment-page-1/#comment-1201 The author suggests keeping the domain model completely clean and unaware of underlying persistence. Only some ServiceLayer is needed to convert domain objects to/from persistence objects and as I understood this involves also CRUD operations. But I want to know what happens if we introduce some ORM into this scenario. As I understand, the right way is to create domain model first and only after that think about how this model will be persisted with or without ORM. Let’s say, we have designed some domain model and now want to use ORM tool for easier persistence. ORM tool lets us generate some entity model and it is just logical that we’ll try to match this entity model with our domain model as closely as possible. But then we get some kind of duplication! We have a domain model with business logic in it and we have the same domain entities but with CRUD or various persistence attributes (maybe not visible but inherited from some base-class or interface). Then the question is - how good or bad idea is to merge our domain model with the ORM generated entities? When is it acceptable and allows us to say that we still have a good domain – driven design and when it is not acceptable because of too much “persistence aware” domain? Is it some trade-off thing going on here (clean domain entities versus duplicated entities)? I found this article: ibm.com/developerworks/java/library/j-pop1/ where they use some base classes and interfaces to implement common functionality in the domain model. But still the model entities contain some persistence awareness because of that inheritance. How good or bad is it from the point of view of clean domain model? Also the same problem arises when we try t
That's a long story, and I'm no academic. I'll try to formulate an answer, and (I hope) others will correct me where I go wrong :)
midix wrote:
where they use some base classes and interfaces to implement common functionality in the domain model. But still the model entities contain some persistence awareness because of that inheritance.
You can define a three-tier architecture where you keep all your persistence-related stuff in the DAL. The BL, although it inherits from the base-class, can be separate from the DAL - even physically on another machine if needs be. Yes, there will still be a relation between those two. The things are loosely coupled, instead of intermixed throughout the entire codebase. Loose coupling has the advantage that you can replace it quickly, simply by writing new derived classes (or new base-classes). You cannot avoid the coupling completely; there's some part in your application that needs to know where to persist, and how.
midix wrote:
And if we forget for a moment about that ServiceLyer but stick to the classical MVC - then where is the right place for CRUD operations when using ORM? Is it Controller or Model?
I'd say neither. Your controller could populate the model with information from the BL-classes, which could be derived from the DAL-classes. Even if you don't follow the three-tier architecture; the controller isn't forced to do SQL - but it sure is convenient if you can LINQ there :)
I are troll :)