Persistence-Ignorant Objects – Can They Implement Lazy Loading?

design-patternsdomain-driven-designdomain-modelpersistence

Persistence Ignorance is an application of single responsibility principle, which in practice means that Domain Objects (DO) shouldn't contain code related to persistence, instead they should only contain domain logic.

a) I assume this means that the code which contacts lower layers ( ie persistence layers ) lives outside of the domain model in other classes ( OC ) of a business logic layer?

b) If my assumption under a) is correct, then DO, say Customer, never contains methods such as GetCustomers or GetCustomerByID?

c) If my assumptions under a) and b) are correct, and assuming Customer domain object uses lazy loading for some of its properties, then at some point Customer's internal logic must contact OC, which in turn retrieves deffered data. But if Customer needs to contact OC to receive deffered data, then we can't really claim that Domain Objects don't contain logic related to persistence?!

Thank you

REPLYING TO jkohlhepp

1) I assume OrderProvider and CustomerProvider classes are contained within business logic layer?

2) I gather from your reply that my assumptions under b) are correct?

… I would check to see if some private orders field was populated or
if it was null. If it is null …

But as far as I can tell, as soon as domain code needs to check whether private order field was populated, and if it isn't,contacting OrderProvider, we are already violating PI principle?!

Best Answer

I believe you are correct in your assumptions A and B around persistence ignorance.

How you would best accomplish lazy loading of database objects is greatly dependent on your particular problem and implementation. However, I will attempt a generic answer to how to do lazy loading while still maintaining separation of concerns between persistence and domain logic classes.

I tend to implement persistence ignorance using the following classes:

Domain classes - e.g. Customer
Provider / repository classes - e.g. CustomerProvider
Generic database querying classes - e.g. DatabaseQuery

The DatabaseQuery class would be responsible for using the database driver to query the database and assemble the resulting data into a generic result set such as a DataTable. The CustomerProvider would be responsible for using the DatabaseQuery class to execute SQL against the database and use the results of that SQL to assemble Customer instances. Customer would be "pure" domain object that contained data and logic related to customers.

As for whether the provider classes should be in the business tier or the data tier, I don't have a strong opinion. I can see a case for both. The important part is that you separate the responsibilities across classes.

So now let's discuss lazy loading. Let's say I wanted Customer to have a collection of Orders, but I don't want to pull Orders out of the database unless the consumer tries to access them. I would create a property on Customer called Orders. In the getter of that property, I would check to see if some private orders field was populated or if it was null. If it is null, load the orders from the database using an OrderProvider. Otherwise, just return the collection that was already loaded.

In my opinion, the need for Customer to contact OrderProvider does not violate PI. Customer still doesn't know how it gets orders. It just knows that it gets them from OrderProvider. There might be other reasons to decouple Customer from OrderProvider, but I don't think PI is a problem here.

This assumes that you are doing persistence ignorance manually. If you are a using an ORM framework such as Entity Framework or Hibernate, then those frameworks generally have features for supporting lazy loading automagically.

Related Solutions

ORM – Achieving 100% Persistence Ignorance Without ORM’s POCO Objects

After coming across the same problem, here is the solution I implemented for it.

Domain

public class DomainObject : AggregateRootBase //implements IAggregateRoot
{
    private ChildEntity _ChildEntity = null;
    public ChildEntity ChildEntity
    {
        get
        {
            OnChildEntityRequested();
            return _ChildEntity;
        }
    }

    public event EventHandler ChildEntityRequested;
    protected void OnChildEntityRequested()
    {
        if (ChildEntityRequested != null) { ChildEntityRequested(this, new EventArgs()); }
    }

    public static void SetChildEntity(DomainObject destination, ChildEntity child)
    {
        //To set or not to set, that is the question.
        destination._ChildEntity = child;
    }
}

Repository Implementation

public class DomainObjectRepository : List<DomainObjectTracker>, IDomainObjectRepository
{
    private void Load() //Method called by constructor or other loading mechanism.
    {
        foreach (DomainObjectDataModel dodm in ORMSystem) //Iterating through each object returned from ORM.
        {
             DomainObject do = Translate(dodm); //Translate into domain object.
             do.ChildEntityRequested += new EventHandler(DomainObject_ChildEntityRequested);
             DomainObjectTracker tracker = new DomainObjectTracker(do, dodm.Key);
             base.Add(tracker);
        }
    }

    protected void DomainObject_ChildEntityRequested(object sender, EventArgs e)
    {
        DomainObject source = sender as DomainObject;
        //Here, you could check to see if it is null or stale before loading it.
        //if (source.ChildEntity == null || IsStale(source.ChildEntity))

        DomainObjectTracker tracker = base[IndexOf(source)];
        ChildEntity entity = LoadChildEntity(tracker.Key); //Load the child entity from ORM.
        DomainObject.SetChildEntity(source, entity);
    }
}

After examining my solution, you may be thinking, "Isn't calling an event infrastructure related code, it certainly doesn't relate to my domain?". While that may be true, if you think about it solely in terms of PI, then you realize that you're just offering a message from your domain saying, "Hey, I'm about to access this child entity." which allows your repository to respond with, "Hold on, if you need one (or a new one), I got it right here in my db so let me give this to you before you continue!".

There are a few caveats here. One, it means that you need an event for every child entity within an aggregate. Two, it breaks encapsulation because you are allowing a public way of setting the child entity. On the flip side, the benefits are expressive code, infrastructure implementations are easily separated from the domain, domain objects are PI, and the ORM remains encapsulated behind the repository implementation.

If someone has a better way of solving this problem, I'm all eyes!

EDIT Also, even though my answer provides a solution for PI, I agree with the commenters above. You need to evaluate if DDD is even the right answer for you because, while it makes a project easier to maintain and simplifies what would otherwise be a highly complex project, it comes at a cost (usually up-front development time and training your team to organize code properly and utilize the various patterns).

Domain-Driven Design – Validating Domain Model Rules with Database Content

How complex are the validations? Often validations require a combination of fields and or business rules that rely on fields to be accurately evaluated.

The more complex the validations, the harder and less performant option #2 is.

Of course the data tier could invoke the validation service at persistence time. This could help the odd situation where data is in an invalid state due to a change in rules.

The other item worth commenting on is the ability for a change in validation rules without a qa cycle of some sort. But that is a topic for a different thread.

Given the information above, option 1 seems the most flexible assuming you maintain discipline, separating validation and persistence.

Best Answer

Related Solutions

ORM – Achieving 100% Persistence Ignorance Without ORM’s POCO Objects

Domain-Driven Design – Validating Domain Model Rules with Database Content

Related Topic