What is the difference between a ORM, AR, QB, & DM? - php

Question

Ok, so everyone has decided (and for good reason) strait SQL is of the devil. This leaves us with many methods of placing a "middle-man" in our code to separate our code from the database. I am now going to spit out all the info I have gathered in the hope someone can set me strait and tell me what I built.
An ORM (Object-relational mapping) is a series of tools (loosely or tightly integrated depends) which maps database rows to objects in the application.
In an AR (Active-Record) is a type of ORM in which a database table or view is wrapped into a class, thus an object instance is tied to a single row in the table.
Data mapping (DM) is a type of ORM that is the process of creating data element mappings between two distinct data models.
All three claim to work like this:
$user = new User();
$user->name = 'Fred';
$user->save();
Usually with a User class something like this:
class User extends Model {
// Specify the database table
protected $table = "users";
// Define your fields
protected $fields = array(
'id' => array('type' => 'int', 'primary' => true),
'name' => array('type' => 'string', 'required' => true),
'email' => array('type' => 'text', 'required' => true)
);
}
With this setup you can easily fetch rows without the need to write SQL.
// users
$users = $user->fetch(array('id' => 3));
Some AR classes actually look more like this:
$db->where('id' => 3);
$db->join('posts', 'posts.user_id = users.id');
$results = $db->get('users');
Ok, now this is where it gets hairy. Everyone and his brother seems to have a different view on what type of code falls where. While most agree that an AR or DM is a type of ORM - but sometimes the lines that tell AR's from DM's seem to smear.
I wrote a class that uses a single object ($db) in which you make calls to this object and it handles SQL creation for result saving/fetching.
//Fetch the users
$results = $db->select('id, name')->where('id > 4')->get('users');
//Set them active
while($user = $results->fetch()) {
$user->active = TRUE;
$user->save();
}
So the question is "what is it?", and why don't people agree on these terms?

Answer 1

It's not that straight SQL is the devil - sometimes it's pretty much required to write raw SQL to get a query to perform the way you want it to. To me, ORMs are much more about eliminating manual work than anything else (like avoiding SQL at all costs). I just don't want to have to setup all my code objects with all hand-crafted queries for every project. That's just a ridiculous amount of work and thought. Instead, ORM tools provide a nice and automated way to create data objects that would have required a lot of manual work otherwise. Now I can have automatic individual row objects that I can extend and create custom functions for, without thinking about it. I can retrieve related rows from different tables without having to hand-code that query.
It looks like your User class example is from phpDataMapper, and if so, it also has some other built-in niceties like auto table migrations so you don't have to distribute an SQL file for your table structures as well as a few helper functions and other things. All features included intended to save you time - that's the main goal.
The most important distinction between AR and DM is that an ActiveRecord (AR) row knows about it's own data store, and thus has saving/updating functions on each row object - $user->save() - The "record" is "active". With DataMapper (DM), on the other hand, each individual row does NOT know about it's own data store, by definition. The row is more of a dumb value object that can be worked with in your code. The mapper is responsible for translating the changes to that row back to the datastore - $mapper->save($user). That's the most significant difference - you will find most of the core ORM features to be the same in almost any implementation. It's just mostly a matter of how it's put together at the core architectural level.

Answer 2

You might as well make up the acronyms ORM, RM DM whatever ... it is all just state transferred from one medium to another and wrapped in function/semantics.
Sun Microsystems and Microsoft do it all the time with Java and C#. Let's take something simple and give it a new name! What a great idea.
If you say ORM .. everyone knows what it is, in its many guises. Your code looks like the Linq stuff though.
No magic, but alot of buzzwords and fuss IMHO.

Answer 3

Agreed with #Aiden Bell. But I think you are right in pointing out the differences. I use LINQ to SQL which in your definition is simply Active-Record style of ORM. For me this works great as I work on a lot of greenfield apps and start at the db to build out my classes. From there I tend to follow a Domain Driven Design approach (I know...this is a classes first concept) working with my generated classes. To me this gets me down the road quickly.
Having said this I have also worked with Entity Framework and NHybernate. Entity Framework is the UBER data mapper and NHybernate is also a data mapper but without as much complexity! I personally feel that Entity Framework has a long ways to go. If I was ever to need more complexity such as in a brownfield application where the db was fairly set in stone and I needed to get my classes to represent my application rather than my database then I would prefer to move to something more along the lines of NHybernate and its data mapping funcationality.
I think each of these tools has it's place. It is not fair to say that they are all the same as they are not. An active record is great in that it generates classes for me that directly represent my database. This works when I created the database or the database closely represents my ubiquitous terms and concepts of the application. The mapping types of orms work when I have a fixed db that doesn't make sense or clearly map to my application in which case I can encapsulate the complexity or lack there of in my database to create a rich domain via the mapping features of the ORM tool.