We have a software which purpose is to be used to help users build their own applications. It has to be very loose coupled with the infrastructure: for example, I can imagine users running it on MySQL database as well on MongoDB.
We have modules of functionalities. In each module we do have what I call pure models – containing only what is required. For example, a Book contains authors, title, number of pages and so on.
The problem is that we need to bundle additional meta-data with the models that depends on the other infrastructure! Trivial example is a technical key of the Book: for MySql repos this is primary key of the table, some other ids as well; for MondoDB repos is just its own string key. As you see, the meta-data information is not unique and depends on infrastructure.
This additional data is provided by concrete repository implementation, every time when model is stored or retrieved from repo.
Now the problem: we would like to ‘hide’ this from the Book (i.e. model) interface – since there is no sense to bundle all variants of meta data to the Book.
How to solve this?
[A] We can have factories that builds our models, depending on used repo. So for SQL repo, we have a SQL factory, that builds a SQL variant of the model. Not sure that I like this.
[B] We simply add a property to Book for additional meta-data, like repoMetaData. This property is strictly technical, i.e. it is not related to the business. Then any repository implementation may inject whatever inside. Book would become RepositoryAware (an interface).
I like the [B] more, but some don’t like the fact we are adding technical stuff to the book interface. How far it make sense to add additional, technical info to the models?
1
If you group your technical meta data (as you call it) into reasonable classes, I do not see a problem to be part of your Book.
There is just a problem if some of your meta data is needed during the model creation. If this is a case, then you can’t run from factories – or to have instance to providers of those meta data.
The answer i’ve seen most often is to add :
public object MetaData
To the class. Obviously this provides plenty of flexibility, but no type saftey.
Another option would be to add a GUID Id to all ‘entity’ style classes. This would allow consuming classes to implement thier own store of metadata keyed off the Id
1