Data Access Objects (DAO) - Revision history

Jerico.dev: Removed the "two different accessor" approach for dependent objects as it created too much confusion in practice. Better explain and justify the subclassing approach.

2011-03-21T17:57:00Z

Removed the "two different accessor" approach for dependent objects as it created too much confusion in practice. Better explain and justify the subclassing approach.

Jerico.dev: Added a rule for methods that change data.

2011-03-02T00:01:42Z

Added a rule for methods that change data.

Jerico.dev: Small improvements

2011-03-01T06:58:29Z

Small improvements

Jerico.dev: typo

2011-03-01T06:50:19Z

typo

Jerico.dev: Added 3NF

2011-03-01T06:41:54Z

Added 3NF

Jerico.dev: improve layout

2011-03-01T05:44:05Z

improve layout

Jerico.dev: Improved language

2011-03-01T05:41:15Z

Improved language

Jerico.dev: Describe the situation with multiple inheritance levels and hierarchies.

2011-03-01T05:36:17Z

Describe the situation with multiple inheritance levels and hierarchies.

Jerico.dev: Small improvements

2011-03-01T05:30:01Z

Small improvements

Jerico.dev: Describe relation tables with their own properties.

2011-03-01T05:24:42Z

Describe relation tables with their own properties.

@@ Line 96: / Line 96: @@
 If you decide that you cannot serve all use cases by the same set of dependent objects then you can use one of the following strategies to break the dependency chain in a well-defined way:
-=== Use-case specific DAO methods ===
+=== Lazy Load ===
-We can create two different DAO-methods, one that retrieves a fully populated object and another that only retrieves an object with basic values set. This is often the cheapest, simplest and easiest to maintain solution. Of course this means that we introduce a certain dependency between the controller and the DAO but if the methods have at least some potential for re-use then this implementation is often the best. Code duplication should be avoided by sharing re-usable SQL snippets and object population code internally between different accessors.
+The simplest solution often is lazy load. It can provide a good compromise between a simple class design and good performance. Mind premature optimization, though. Using lazy load is a performance optimization technique and doesn't make sense if there is no visible performance impact by instantiating dependent objects right away!! Otherwise the pattern introduces unnecessary coupling between the domain object and other DAOs which increases maintenance cost and is to be avoided.
-−
-Example: Implement a DAO method that retrieves an Author object with it's user group populated and another one that leaves the Author's user group null. The former calls the latter and only adds the user group. We can add an assertion to the DO, i.e. in this case Author::getUserGroup() that makes sure that the accessor is never called when the field has not been populated.
-−
-=== Lazy Load ===
-We can initialize (parts of) an object at runtime when needed by depending on another DAO to retrieve the linked object when needed, i.e.
+Lazy load means to initialize (parts of) an object at runtime when needed by directly depending on another DAO to retrieve the linked object when needed, i.e.
   class Chapter {
@@ Line 113: / Line 109: @@
+  }
-=== DAO inheritance ===
+=== Polymorphism ===
-The most complex solution is that we can introduce subclasses so that we can use the general concept of an entity in use cases where we require less data and only instantiate the the more complex, specialized (and expensive) concept of an entity when really needed. See the inheritance mapper design pattern above for that case.
+If the dependent object is not required in all cases then introducing a subclass may be another possible solution. This solution is only a good one if the subclass really makes sense as a separate conceptual entity. Inheritance is a precious good because there can only be one inheritance hierarchy. If you inherit from another class be aware that you prevent others from doing so later in cases that may better justify inheritance. Therefore you should never introduce sub-classes just to improve performance, use lazy load instead! Always make the "natural language test" to validate your inheritance approach, i.e. saying "subclass abc '''is''' a parent class xyz" should make sense in natural language.
-Please make sure, though, that the entities really implement a semantic concept that makes sense in "natural language", i.e. a concept that is not only introduced for performance but immediately makes sense to those who read the code and those who use the application.
+This also means that the current specializations of Submissions into "ReviewerSubmissions" or "AuthorSubmissions" with their corresponding DAOs are anti-patterns - you shouldn't reproduce those. They couple the DAO to specific controller transactions, break encapsulation and good separation of concerns, produce duplicate code, do not improve performance and not even reduce complexity. They could be implemented much more elegantly with the other design options outlined above.
-The current specializations of Submissions into "ReviewerSubmissions" or "AuthorSubmissions" with their corresponding DAOs are anti-patterns - you shouldn't reproduce those! They couple the DAO to specific controller transactions, break encapsulation and good separation of concerns, produce duplicate code, do not improve performance and not even reduce complexity. They could be implemented much more elegantly with the other design options outlined above.
+Subclassing allows us to only instantiate the more complex, specialized (and expensive) concept of an entity when really needed. See the inheritance mapper design pattern above on how to implement a DAO for subclasses.
 = Common DAO Design Errors =

@@ Line 59: / Line 59: @@
 The first question to answer is where to put your method. You can potentially query objects in both directions of the relation - e.g. you can return an Author object with all Chapters of that author as dependent objects or you can return a Chapter object with all authors of that chapter as dependent objects.
-The basic rule is: You always put your method into the DAO that corresponds to the return type of your accessor. In other words: If you return chapters with authors as dependent objects then you put your method in the ChapterDAO, if you return authors with chapters as dependent objects then you put your method in the AuthorDAO.
+The basic rule is:
 == How to implement different types of relations? ==

@@ Line 37: / Line 37: @@
 To achieve this, the SubmissionFileDAO will delegate to one of the two concrete DAOs when one of its methods is being invoked. It identifies the right DAO either by inspecting the type of the object (on update/insert) or by querying the base table that contains some type indicator (on read access, e.g. genre in the case of the monograph/artwork file distinction).
-To avoid unnecessary database queries the SubmissionFileDAO can also prepare data via outer joins over all class tables to be passed into the concrete DAOs. The methods of the delegates do not necessarily correspond 1:1 to the methods on the public DAO interface. See the separate inheritance hierarchies.
+To avoid unnecessary database queries the SubmissionFileDAO can also prepare data via outer joins over all class tables to be passed into the concrete DAOs. The methods of the concrete DAOs do not have to correspond 1:1 to the methods of the "orchestrating" DAO. That's the reason why they are on separate inheritance hierarchies and why we distinguish between the SubmissionFileDAO and the AbstractSubmissionFileDAO in our example.
 The inheritance mapper design does not prescribe a specific database design (see the three O/R mapping strategies above). We can use all common mapping techniques.
@@ Line 43: / Line 43: @@
 You can use one of the concrete DAOs in your handler but only if you really want to deal with that specific domain object type. If you implement a special artwork file editing form for example it may make sense to use the ArtworkFileDAO directly. Most of the time access through the domain object DAO should be preferred, though, as it will deal with most cases and is easier to extend and maintain.
-Please keep in mind that not all inheritance hierarchies are as simple as this one. There are usually multiple children to one parent class, otherwise inheritance wouldn't make sense after all. There is often not such a clear-cut design, then. You'll have to decide which parts of the inheritance hierarchy need their own "orchestrating" DAO managing concrete DAOs. You can also nest "orchestrating" DAOs into each other so that what is an "orchestrating" DAO on one level appears as a "concrete" DAO from the viewpoint of an "orchestrating" DAO on a higher level.
+Please keep in mind that not all inheritance hierarchies are as simple as this one. There are usually multiple children to one parent class. There is often not such a clear-cut design, then. You'll have to decide which parts of the inheritance hierarchy need their own "orchestrating" DAO managing "delegate" DAOs. You can also nest DAOs into each other so that what is an "orchestrating" DAO on one level appears as a "delegate" DAO from the viewpoint of a parent class.
 = Mapping Relations Between Objects =

@@ Line 23: / Line 23: @@
 * How to map inheritance hierarchies (polymorphism) to database tables via DAOs?
 * How to map relations between objects (composition/aggregation) to the database (one-to-many and many-to-many relations) via DAOs?
-* How trade off performance (runtime, memory) against code re-use/maintainability and complexity?
+* How to trade off performance (runtime, memory) against code re-use/maintainability and complexity?
 = Polymorphism =

@@ Line 1: / Line 1: @@
 = The DAO pattern =
@@ Line 113: / Line 122: @@
 = Common DAO Design Errors =
 == DOs that instantiate themselves via their corresponding DAO ==

@@ Line 116: / Line 116: @@
 == DOs that instantiate themselves via their corresponding DAO ==
-We had cases where a DO instantiates itself via its own DAO and copying this code across the inheritance hierarchy. Don't confuse this with the above lazy-load pattern. While it is ok that a domain object lazy-loads other objects, it's usually not ok that a domain object instantiates itself.
+We had cases where a DO instantiated ''itself'' via its own DAO and copying this code across the inheritance hierarchy. This is ''not'' the same as the above lazy-load pattern! While under some circumstances it may be ok that a domain object lazy-loads other objects via their DAOs, it's not ok that a domain object instantiates itself via its own DAO.
 == Compositions that are not part of the concept of an object ==

@@ Line 18: / Line 18: @@
 = Polymorphism =
-The relational data model does not implement polymorphism out-of-the-box. This means that as soon as DOs are polymorphic we'll no longer have a clean one-to-one relationship between database entities (aka "tables") and domain objects. An object-relational (O/R) mapping will be required. The three standard O/R mappings for polymorphic objects are: Single Table Inheritance, Class Table Inheritance and Concrete Table Inheritance. No description here - descriptions are easily to be found on the web.
+The relational data model does not implement polymorphism out-of-the-box. This means that as soon as DOs are polymorphic we'll no longer have a clean one-to-one relationship between database entities (aka "tables") and domain objects. An object-relational (O/R) mapping will be required. The three standard O/R mappings for polymorphic objects are: Single Table Inheritance, Class Table Inheritance and Concrete Table Inheritance. I won't describe these standards here - they are well documented on the web.
 The standard pattern for an inheritance mapper is like this:
@@ Line 24: / Line 24: @@
 [[Image:Inheritance_Mapper.png]]
-In the given example, the SubmissionFileDAO will often be the only DAO required to handle access to mixed lists of files. Whenever the implementation doesn't matter you'll use the methods of the domain object DAO to access objects from the whole inheritance hierarchy. The DAO will make sure that monograph files will be instantiated as MonographFile and artwork files as ArtworkFile classes.
+In the given example, the SubmissionFileDAO will often be the only DAO required to handle access to mixed lists of files. Whenever the implementation doesn't matter you'll use the methods of the domain object DAO to access objects from the whole inheritance hierarchy. The DAO will make sure that monograph files will be instantiated as MonographFile and artwork files as ArtworkFile classes. It will also transparently convert between implementations when necessary.
 To achieve this, the SubmissionFileDAO will delegate to one of the two concrete DAOs when one of its methods is being invoked. It identifies the right DAO either by inspecting the type of the object (on update/insert) or by querying the base table that contains some type indicator (on read access, e.g. genre in the case of the monograph/artwork file distinction).
@@ Line 33: / Line 33: @@
 You can use one of the concrete DAOs in your handler but only if you really want to deal with that specific domain object type. If you implement a special artwork file editing form for example it may make sense to use the ArtworkFileDAO directly. Most of the time access through the domain object DAO should be preferred, though, as it will deal with most cases and is easier to extend and maintain.
 = Mapping Relations Between Objects =

@@ Line 2: / Line 2: @@
 Typical properties of implementations of the Data Access Object (DAO) pattern in the context of a Model-View-Controller (MVC) application as ours are:
-* The DAO maps the relational database model to an OO model thereby bridging the "impedance" mismatch of these two data modeling approaches. It also sometimes hides implementation details of specific storage technologies (e.g. different database vendors). The latter is often, at least partially, delegated to a special data access abstraction layer, though (i.e. ADOdb in our case or maybe PDO in the future). This decouples the controller from the relational data model and from database implementation details.
+* The DAO maps the relational database model to an OO model thereby bridging the "impedance mismatch" of these two data modeling approaches. It also sometimes hides implementation details of specific storage technologies (e.g. different database vendors). The latter is often, at least partially, delegated to a special data access abstraction layer, though (i.e. ADOdb in our case or maybe PDO in the future). DAOs are designed to decouple the controller from the relational data model and from database implementation details.
 * The DAO usually implements a basic "Create-Read-Update-Delete" (CRUD) pattern to handle single instances of entity objects.
-* Most of the time additional use-case specific methods are required that batch-retrieve objects to improve data access performance or populate objects differently, e.g. with or without dependent objects loaded.
+* Most of the time additional use-case specific methods are required that batch-retrieve objects to improve data access performance, populate objects differently, e.g. with or without dependent objects loaded and deal with polymorphism.
-* The DAO will usually return domain objects (DO) that represent instances of data entities (e.g. articles, users, etc.).
+* The DAO returns domain objects (DO) that represent instances of data entities (e.g. articles, users, etc.).
-* DOs contain either only values or in more recent design paradigms (domain driven design, DDD) values & domain-specific behavior. In our case we mostly stick to the value-only approach but exceptions confirm the rule and there's not problem with that.
+* DOs contain either only values or in more recent design paradigms (domain driven design, DDD) values & domain-specific behavior. In our case we mostly stick to the value-only approach but exceptions confirm the rule and there's no problem with that. We do not usually use the data transfer object (DTO) pattern in the sense of untyped objects created on the fly to represent use-case specific data. There may be exceptions to this rule but you should try to always return fully populated DOs for better re-use of DAO methods.
 * DAOs usually instantiate DOs and not the other way round except when implementing lazy-load (see below). If you can choose then you should avoid dependencies from the DO to the DAO to improve encapsulation.
 = DAO design problems and trade-offs =

@@ Line 42: / Line 42: @@
 * To which class belong(s) the object(s) you return?
 * Do you implement a one-to-many relation and the related objects are only being used in the parent object? Or do you implement a one-to-many relation with an object that is (also) being used independently of the parent object or do you implement a many-to-many relationship?
 * How expensive are simpler design options in terms of execution performance? What is the cost of additional complexity of different design options and what is the maintenance cost?
@@ Line 66: / Line 67: @@
 # If this implementation is too expensive then you can load all related objects at once by implementing a corresponding method in the DAO of the related object. This implementation still keeps all SQL and object instantiation code for the related object in it's own DAO thereby improving encapsulation and code re-use. The disadvantage is that you'll have to implement specialized accessors that cannot be re-used as frequently as the basic accessors of the DAO.
 # If this implementation is still too expensive then you can create a single SQL query that draws all required data together in the parent object's DAO and only delegate to the related object's DAO for object instantiation (calling its fromRow() method). This is the most performant method as it minimized the required roundtrips to the database. But this method requires much more complex code, breaks encapsulation and reduces re-use. It therefore only makes sense when you really have a noticeable performance problem to solve.
 == When to load dependent objects? ==