I suppose the key term in ORM is "object persistence". Rather than considering things as rows, records, and tables (RDBMS) you want to work solely in terms of objects, with all the OOP goodness that implies. So for every dataset, you have a specific object each of which can reference other objects (e.g. a Book Object holding references to individual Chapter objects).
If you were designing a space strategy game, you would require Fleet, Ship and Location objects. Each Ship would carry a reference to its member Fleet, etc. The question becomes how to take those objects and store them between requests - i.e. persistence. The obvious solution is to a database. Of course a database (unless a newfangled OD) is typically relational - it stores scalar values not objects. So ORM is the method used to map Objects to record(s) on a database (being the main method of object persistence) and back again.
If you take a simple example (let's presume a 1-1 Object->DB Row mapping) - you have a User Object. This object has id, name, email and website properties. In the simplest type of mapping, each User refers to a database table record with its properties mapping to fields on that record. Creating and storing a User includes a few steps:
1. Assigning property values
2. Generating INSERT sql
3. Executing the INSERT
4. Assigning the id (a table primary key with auto increments) on the origin User Object.
Steps 2-4 are common to the similar Data Access Object pattern - it's a simple CRUD operation.
Updating a User follows the same pattern - optionally a User object could track which fields change to limit the UPDATE statement.
Fetching a User should rely on the primary key with a fetch method like:
Where things get complicated is when you depart a strictly 1-1 mapping. Say we decide our User object will hold a reference to a Settings object. So we can grab settings using $user->settings->somekey or $user->getSettings()->get('key') whichever is preferable. This is perfectly acceptable in OOP but our ORM system now needs to recognise that a User object can map to 2 tables - the object is persisted on two rows - a user record and a settings record, likely linked by a foreign key (user id probably).
Still. Creating our object should stay simple.
Code: Select all
$user = new User;
$user->name = 'Jenk';
$user->email = 'jenk@example.com';
$user->website = 'http://www.example.com';
$settings = new Settings;
$settings->somekey = 'somevalue';
$user->settings = $settings;
$user->save(); //also saves Settings automatically and handles assigning the user's id primary/foreign key
Back to some of the syntax. __get and __set (or named accessors) are usually needed for these kinds of objects since setting a value can require some additional work - also it makes it simpler to refactor later. You might want to track which fields are changed, or handle values from any assigned objects. You'll also likely have other methods in such objects to check existence (is the object new, already persisted, in need of an update?) among other things.
Here my ramble ends...

. Not sure if that was an okay explanation or if it's still a bit vague for what you wanted...