DataMapper ORM v1.8.2

[eluser]WanWizard[/eluser]
Most of Fowler's book doesn't apply, because contrary to what the name would suggest, Datamapper implements the Activerecord pattern, not the Datamapper pattern (blame my predecessors ).

In an Activerecord pattern there's a one-on-one mapping between the object and it's table row, and both code and data is a single object. This makes it very complex to create data structures that aren't a one-on-one mapping to a table, so inheritance and polymorphism are "very difficult" to implement.

Another point is most people use the ORM the wrong way. If you read up on it, you'll notice that outside code should interact with model methods, and model methods interact with the datastore.

That means you should not use this in your controllers:

Code:

$user->where('group', 'admins')->where('status', 'active')->get();

but

Code:

$user->get_active_admins();

The last option allows you to hide complex code from your controllers. You get an object back, you don't know from where the data came. Could have been a webservice instead of a table. Or from different tables (in your theoretical case).

Unfortunately most ORM's provide strong query builder features, stronger than the native framework solution, so people tend to use the ORM as a glorified query builder. Most never get any further with their models then added a table name, relations, and sometimes some validation.

With the Datamapper pattern you have separate data and code objects. Often a Datamapper based ORM doesn't include a query builder, but relies on an external DBAL, which forces you to either use DBAL calls in your code (think $this->db) or ORM method calls. But you can't use DBAL calls through ORM objects.

It's one of the biggest issues I'm struggling with for the design of 2.0. Ideally I would like this separation, but it would mean breaking with the past, and an upgrade nightmare. 2.0 no longer uses the frameworks QB (no more $this->db in the case of CI), but will come with it's own DBAL (I'm going to use http://github.com/FrenkyNet/Cabinet), if only because I no longer want to be dependent on the CI dev's making changes to the libraries that require hacks to make DM work again.

I'm currently trying to work my way out of this dilemma, by seeing if it's possible to use a 'legacy' extension with would re-introduce DBAL access through the ORM for migration purposes. But I haven't made up my mind yet.