Patterns for a tree of persistent data with multiple storage options?
- by Robin Winslow
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?
