DataSourceORM

DataSourceORM is a object-relational mapping solution written in PHP and loosely based on the concept of delegation of database operations from the model to a datasource.

The term model is used here because DataSourceORM is really designed to be the 'Model' component in a 'Model View Controller' system. The components can be used elsewhere without issue, but this is its intended use.

Why DataSourceORM over alternatives like Doctrine or Propel?

Architectural reasons aside, the basic approach DSORM uses is different to solutions like Doctrine/Propel. DSORM can be considered a zero-configuration library. That's not entirely accurate, as you of course need to give your database connection details, but you do not need to define your schema in an XML or YAML file, or through any other method. This makes DSORM easier to use and more portable, but it does mean some advanced features are sacrificed as DSORM is unable to analyse the schema with class definitions.

Essentially, the advantages of DSORM are:

• You can get straight into coding - all you need to tell the ORM is the database name and connection details.
• It is much easier to deploy, as long as the database can be connected to, it'll work without extra configuration.
• It is conceptually simple, so easy to modify and understand. There is also not a huge amount of code to trawl through.
• There is clear separation of Model logic and Database logic, so you can much more easily use the same interface for your models that interact with a database layer and your models that use file IO or network connections amongst other things.
• You won't need any build scripts or automation to regenerate class definitions after schema changes or visa versa.

However, the disadvantages are:

• You must maintain your schema and your class definitions separately, essentially creating a duplication of information between the two. Many ORMs let you either generate the schema from class definitions, or generate the class definitions from the schema.
• There is no independence from a database. In cases where ORMs can generate the database on the fly from a schema definition it is much easier to create independent unit tests as part of your build process or otherwise.
• Lack of knowledge about the schema's relationship with class definitions mean that many advanced features, such as automatic converting of foreign keys to the classes that correspond with the tables they have relationships with, are not possible to automate and must be coded manually (although this is not difficult, complex, or lengthy – just a simple object instantiation.
• More complex ORMs tend to provide abstractions for dealing with other types of common SQL queries, whereas DSORM does not (though it is a simple process to convert the results of one of these types of queries into an object).

Examples

Imagine the following table:

name (primary key)	manufacturer	colour	type
MacBook	Apple	white	notebook
MacBook Pro	Apple	silver	notebook
Eee PC	ASUS	white	netbook

Assuming the correct models were set-up, you could manipulate this dataset with the following code:

Retrieving Records

$appleMacBook = new Product('MacBook');

echo $appleMacBook->getColour(); // 'white'

$appleMacBook->setColour('black');
echo $appleMacBook->getColour(); // 'black'
$appleMacBook->save(); // this update is committed to the database with an UPDATE query

Creating Records

$macBookAir = new Product;
$macBookAir->setName('MacBook Air');
$macBookAir->setManufacturer('Apple');
$macBookAir->setColour('white');
$macBookAir->setType('subnotebook');
$macBookAir->save(); // this is committed using an INSERT query