php[architect] logo

Want to check out an issue? Sign up to receive a special offer.

ORM Designer

Posted by on May 12, 2010

The support of object-oriented programming in PHP 5 opened the field for new kinds of general-purpose libraries, and in particular for object-relational mappers used to persist the objects used throughout a PHP application in a classic relational database such as MySQL or PostgreSQL.

Metadata specification

For an ORM to work, there are different data models that has to be kept in sync: the object model defined in the PHP source code, the relational model represented by the database schema, and the mapping metadata which configures the ORM to translate between the two.

As with all duplication problems, some of this models may be derived from their equivalents. For example, the simplest ORMs infer the object model from the list of tables in the specified database. There are more sophisticated approaches, like defining at least the metadata to configure the ORM and generate the object and relational model from these mapping configuration. Doctrine 1 and other ORMs makes wide use of this technique.

An even more resilient approach is to define explicitly an object model and its metadata in the form of annotations embedded in PHP code or XML documents, and to generate only the relational schema (as Doctrine 2 does.)

Visual design of metadata

The application reviewed in this article, ORM Designer, is a visual design tool for PHP object-relational mappers. Developers can define an unified model via a graphical interface, and derive the ORM configuration (object and relational model plus the mapping metadata) automatically from the unified model.

Visual designing tools have to be taken with a grain of salt, as there is no fine control over their results when used for code generation. Furthermore, the generated products have to be kept in sync with the evolving unified model via regeneration, and this raises issues with further editing.

ORM Designer pays particular attention to these issues. The unified model is stored in human readable XML, and it is the source of all the generated code. The advantage of XML over a binary format resides in the possibility of diffing different versions of the model and storing it efficiently in source control systems. Of course this unified model can be exported in a format thatcan be understood by the ORM. In the case of Doctrine, which is the primary target of this designing tool, Yaml would be the format of choice.

The ORMs currently supported by ORM designer are Propel and Doctrine, plus the model system of CakePHP (Zend Framework and symfony projects usually employ Doctrine to implement ORM functionalitites). Support for Doctrine 2 is under development, because due to the versatility of the ORM there are some issues in implementing visualization for features like inheritance and annotations.

ORM Designer runs on nearly every platform: Windows, Mac OS X and Linux with wine. I have tried it on Ubuntu 10.04 and there no issues on functionality nor slowness due to the use of wine. The graphical interface is very close to the simplicity of Microsoft Access, but of course the generated source code is much more powerful as it can be used on many different enterprise database vendors.


Marco is the keeper of keys and Chief Garbage Collector at Blue Parabola. He can be found on Twitter as @mtabini.
Tags: , , , , ,
 

Leave a comment

Use the form below to leave a comment: