So there's Object Relational Mapping, which I've already discussed and decided is just not the right way to do things. Recently when looking into NoSQL systems (particularly, MongoDB) it occurred to me to wonder what the ORM equivalent was? Turns out its ODM... Object Document Mapping, since MongoDB deals with documents rather than tables and relations.
Which made me think some more. What do ORM and ODM have in common? What are we really doing here? Maybe there is something more generic going on, that transcends objects and relations and documents.
In typical MVC frameworks, the Model uses ORM to do its thing... the ORM pretty much IS the Model.
So really we are talking about Model being mapped to a Data Store. A model is an object usually, but couldn't a model just as rightfully be just an array? Couldn't it be a set of objects and/or arrays? Could a model be an arrangement of bits on a disk platter? And the data store, that could a relational database, a document database, a flat file, or just an object or array, etc. See where this is going?
The ultimate simplification here is just a Model to Model Mapping. Where the model can be an array, an object, a data store, a remote api call, etc. And a Model is just one way of looking at some data. It is what its name says. Its not data, its a model of data.
When you use ORM, or ODM, what you are doing is transforming data from one form into another. And there's a lot of places where data is being transformed, not only just when you go to persist the data. When your system accepts data from a web form, its transforming it (which includes validation and filtering, requirements checking, etc). When you make an API call you might transform that data into multiple chunks of data which are passed to objects which then further transform that into a form persistable in a database. And so on.
This I think really is much more in the spirit of what a model was supposed to be in the original MVC concept. Its not supposed to be (just) a wrapper around a database. Its meant to present a conceptual data construct to the user, something that makes sense to the user, not something dictated by the requirements of some (to the user) arcane internal representation.
