ORM and Models: In-depth Review

What is ORM and what restrictions does it impose.

ORM stands for object-relational mapping.

http://en.wikipedia.org/wiki/Object-relational_mapping

ORM is responsible for storing data and describes its structure validating it for insertion and updates.

We have managed to reduce the common ORM restrictions to just two of them:

• the data should be saved as ORM objects (otherwise, data integrity may be affected);
• to retrieve the “one-to-many” relations, it is necessary to check with the relations table.

The ORM does not include tools for retrieving object lists and related object data.

Models containing the query logic are responsible for building data queries.

The models are instantiated by Model::factory('objectname') method and may be of two types:

• virtual - if no additional model logic has been defined, the model factory will return a link to the object containing a set of standard query methods;
• extended (real) - are used in case the query logic needs to be extended.

Extended models are easy to create: Model_Objectname class inherited from Model is added to the /models directory and shows the additional logic of handling the object data, like additional methods building queries with predefined parameters and conditions (Factory will automatically retrieve the class and return a link to the related object).

When implementing extended models, one should remember that late static binding is used when manipulating models, which requires special caution to be observed.

Besides, keep in mind that to ensure the flawless performance, object controllers and models should carry the same names, e.g.:

• object:  news;
• model:  Model_News;
• admin controller: Backend_News_Controller.

Within your models you may use even direct SQL requests for data queries. Herewith, Zend_Select and Zend_Db are recommended, while the database connection url is available by requesting $this->_db and contains the Zend_Db_Adapter object. $this->table() method returns the  full name of the database storing the object data.

The model also includes a link to data cache  $this->_dataCache, which shows either false (if cache is disabled) or a link to the driver implementing Cache_Interface.

ORM has both standard fields and links, such as:

• links to objects object ID is accepted as data;
• links to object lists an array of object IDs is accepted as data;
• links to dictionaries: a dictionary key is accepted as data.

The peculiar thing about our ORM is that it uses models for building queries.  That is to say, there is no need to extract the whole hierarchy at once, as the models are able to retrieve just the necessary data.

Starting from 0.8.7 DVelum version, it is possible to redefine database connection for a certain model, which allows to segregate data on multiple database servers, which do not have to be necessarily mySql servers.

Please note that changing object structure does not lead to revalidation of the existing data, which may cause trouble.

To add to this, one should take into account that the current ORM version operates in the light+permissive mode, which means that removing an object does not presuppose checking for entities linking to it, while the interface shows the status “removed”.

As DVelum is primarily a development environment, you are free to act as per your own preferences, while we are just trying to make things easier for you. Our ORM has been engineered so as to keep the direct query troubles to a minimum.