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.
4 comments:
This post feels a bit open ended. What is your suggested solution?
Currently, I am using CouchDB without and ODM. I'm considering switching to MongoDB instead paired with Mongoose which is an ODM.
What is your recommendation? Don't use ODM?
It certainly was open ended. Now, I had been formulating a solution, and started working on an implementation, but it never went anywhere (switching jobs, projects, etc, got in the way). I don't know of any existing solution that embodies what I had in mind. I've been using, lately, Symfony2 framework and Doctrine2. I know thats a huge ORM system. But I do like the way it lets you define "entities" which begin as Plain Old PHP objects and then you add annotations which tell the framework how to persist it in the database, and how to convert it into an HTML form on the fly. That was sorta what I had in mind. I also like how doctrine can then look at your object changes and make the needed changes to the DB schema automatically.
As you said, models are meant to present a conceptual data construct to the user. If tools like ORM or ODM transform data from one form into another... and controllers should talk to models... should't we use those tools in our models?
The problem for me is that the typical ORM/ODM is intrinsically linked to the database, instead of being something more generic. Doctrine, while interesting in what it does, I think doesn't go in the right direction. I guess I am thinking something more like a generic Data to Data mapper that would handle the transformations from one end to the other -- Forms to Model to Models to Database / API / whatever...
Ultimately it seems like controllers should eventually be generic requiring almost no coding, the model would describe everything. The views should be generated on the fly..
Post a Comment