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
    I would not treat Key as infrastructure specific information, it would be common property for any infrastructure and should kept with the model. Any other infrastructure specific information do you have in mind? Jun 6, 2016 at 23:40

2 Answers 2


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

  • Or define some new abstract ID type for the purpose.
    – Erik Eidt
    Jul 12, 2015 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.