Question

I have a real-world problem which I’ll try to abstract into an illustrative example.

So imagine I have data objects in a tree, where parent objects can access children, and children can access parents:

// Interfaces
interface IParent<TChild> { List<TChild> Children; }
interface IChild<TParent> { TParent Parent; }

// Classes
class Top : IParent<Middle> {}
class Middle : IParent<Bottom>, IChild<Top> {}
class Bottom : IChild<Middle> {}

// Usage
var top = new Top();
var middles = top.Children; // List<Middle>
foreach (var middle in middles) {
    var bottoms = middle.Children; // List<Bottom>
    foreach (var bottom in bottoms) {
        var middle = bottom.Parent; // Access the parent
        var top = middle.Parent; // Access the grandparent
    }
}

All three data objects have properties that are persisted in two data stores (e.g. a database and a web service), and they need to reflect and synchronise with the stores. Some objects only request from the web service, some only write to it.

Data Mapper

My favourite pattern for data access is Data Mapper, because it completely separates the data objects themselves from the communication with the data store:

class TopMapper {
    public Top FetchById(int id) {
        var top = new Top(DataStore.TopDataById(id));
        top.Children = MiddleMapper.FetchForTop(Top);
        return Top;
    }
}

class MiddleMapper {
    public Middle FetchById(int id) {
         var middle = new Middle(DataStore.MiddleDataById(id));
         middle.Parent = TopMapper.FetchForMiddle(middle);
         middle.Children = BottomMapper.FetchForMiddle(bottom);
         return middle;
    }
}

This way I can have one mapper per data store, and build the object from the mapper I want, and then save it back using the mapper I want.

There is a circular reference here, but I guess that’s not a problem because most languages can just store memory references to the objects, so there won’t actually be infinite data.

The problem with this is that every time I want to construct a new Top, Middle or Bottom, it needs to build the entire object tree within that object’s Parent or Children property, with all the data store requests and memory usage that that entails. And in real life my tree is much bigger than the one represented here, so that’s a problem.

Requests in the object

In this the objects request their Parents and Children themselves:

class Middle {
    private List<Bottom> _children = null; // cache
    public List<Bottom> Children {
        get {
            _children = _children ?? BottomMapper.FetchForMiddle(this);
            return _children;
        }
        set {
            BottomMapper.UpdateForMiddle(this, value);
            _children = value;
        }
    }
}

I think this is an example of the repository pattern. Is that correct?

This solution seems neat – the data only gets requested from the data store when you need it, and thereafter it’s stored in the object if you want to request it again, avoiding a further request.

However, I have two different data sources. There’s a database, but there’s also a web service, and I need to be able to create an object from the web service and save it back to the database and then request it again from the database and update the web service.

This also makes me uneasy because the data objects themselves are no longer ignorant of the data source. We’ve introduced a new dependency, not to mention a circular dependency, making it harder to test. And the objects now mask their communication with the database.

Other solutions

Are there any other solutions which could take care of the multiple stores problem but also mean that I don’t need to build / request all the data every time?

Answer 1

You are really asking about two unrelated problems. Yes, the Repository Pattern should result in extraction of items from a store where the items themselves (the Entities) know nothing about the store. So you generally have repositories that implement CRUD and every time you need an entity you get them from there. I don’t see the point of the mapper, nor why you need that middle class.. ?

The second question is how to deal with large trees that are constructed perhaps not all at once. Since you flagged this with design patterns, it’s appropriate to suggest that the tree classes should implement Composite and instead of a ‘mapper’ you should have a Builder. Then that Builder must be able to construct things in phases. That’s an interesting problem. In the Dependency Injection world, this is further complicated by OpenSessionInView.

Try to think about a version that will not have classes for mere positional distinctions, I think Composite will make that possible.