ActiveRecord Pattern and Layer Supertype - Domain Model and Domain-Driven Design
by David Hayden ( Sarasota Web Design )
Filed: Design Patterns
In my recent post about the ActiveRecord Design Pattern:
I discussed the very useful ActiveRecord Design Pattern in the Domain Layer of my blogging engine for my website.
Per the previous article, the ActiveRecord Pattern is great for those domain models where the business object properties in the domain layer have a 1:1 relationship to database table columns in the relational model. In these cases you don't need the sophisticated needs of a data mapper to map business objects across many tables. The ActiveRecord Design Pattern also works best in situations where there are few business rules and hence the addition of persistence methods to the domain objects don't cause a distraction to the business objects themselves. The ActiveRecord Pattern works particularly well in forms-over-data applications, like a blogging engine :)
Layer Supertype
As you begin to add persistence methods and additional code to track the state of the business objects ( New, Dirty, Deleted, etc. ), you will come across a lot of redundant code among the domain objects. This redundant code is ripe for refactoring to a Layer Supertype:
- Layer Supertype: “A type that acts as a supertype for all types in its layer“ ( Fowler, POEAA, p.475 )
Hence, the Post Domain Object in our Domain Layer mentioned in the previous article likely would inherit from a base class that included all the refactored common functionality while the domain objects would only contain specific domain object details. The internal class BusinessObject is the layer supertype.
public class Post : BusinessObject
{
// Domain Object Specific Items
}
internal class BusinessObject
{
// Refactored Common Functions...
protected int Save()
protected int Update()
protected int Delete()
}
Certainly you don't have to create a Layer Supertype for domain objects, but not doing so will certainly cause some redundant code. All ActiveRecord Patterns that I have created and witnessed have always used a Layer Supertype.
ADO.NET SQL Helper Classes Like Enterprise Library DAAB
In the ActiveRecord Pattern in the Domain Layer the database persistence functionality is being encapsulated within the business objects themselves. No matter whether you use Connected ADO.NET Classes or Disconnected ADO.NET Classes, you will find redundant ADO.NET code all over your ActiveRecord Objects. This ADO.NET code will need to be refactored into the layer supertype, and my recommendation is to use an SQL Helper Class like the Enterprise Library DAAB.
internal class BusinessObject
{
// SqlHelper - Enterprise Library DAAB
Database _db;
// implemented in domain object
protected abstract DbCommand GetSaveCommand()
protected int Save()
{
_db.ExecuteNonQuery(GetSaveCommand());
// ...
}
}
In the case above, the domain object is responsible for creating a DbCommand object for persisting itself since this has some domain object specific persistent information in it, but the Layer Supertype, Business Object, is responsible for using the Enterprise Library 2.0 DAAB and persisting the object to the database. BusinessObject would/could also reload the object for any default properties and an autogenerated PK if necessary as well as register the object into a registry so it only gets loaded once for the session ( Identity Map ), etc.
Conclusion
Hopefully the past two articles are providing some good information on the ActiveRecord Pattern and its usefulness in the Domain Layer. There is more to come on this wonderful Domain Model Design Pattern.
Source: David Hayden ( Sarasota Web Design )
Filed: Design Patterns