Blog

ORM, that magical acronym that can send developers into a flurry of excitement, or the rolling eyes of grief. ORM stands for Object Relational Mapping. Used correctly, this can really help applications convert data into objects ready to use. While it does cause some overhead, the key thing to remember is that used properly, it can be really helpful. But that is also the way it is with anything related to code. Since I focus mainly on the open source areas, examining an ORM tool will be limited to the PHP view and aspect.

When designing the data objects, it is important to understand the data and how it relates to the application and other objects. Usually it is the planning sessions that get overlooked, or hurried, and create a problem for later on. This is why using a tool to help with this is always good. I specifically look for more of an ERD (Entity Relationship Diagram) type of tool that can help me visualize and document the data objects. Never underestimate the power of a visual diagram for data. This is worth everything when coming on a new project, or bringing in new resources to a major project. It can drastically decrease the learning curve. There are different tools out there that can help with ERD and ORM design, with the basic Visio diagrams (a Microsoft product), to more robust ERD tools that include different UML (Unified Modeling Language) tools integrated with it like MagicDraw. Each tool will have its pros and cons, no matter what the toolset is, no matter what the project is. I have found that there is not a single tool that is perfect for every project. But finding a good tool that can help in designing the database is a must. If it can even generate code, that is a lot better. One tool that is available that can help with ERD, and generate code, and help with ORM is ORM Designer. And I will examine this tool as it relates to Symfony, CakePHP and non framework applications.

First off, lets answer a few questions:

1. Why do I need to have an ORM designer if I am not using Propel or Doctrine?
   • You don’t, quite simply. The ORM Designer tool is not just for help with ORM items. It greatly helps in ORM, but is a great tool for ERD design. That may be selling it a little short, but it is very handy for that as well.
2. I use CakePHP and need to help generate the code for the models, will this help?
   • Short answer yes, long answer no. This will help you design the data objects. But if you do not understand the data objects, and how they relate with each other and the actions acted upon the data, then it will not solve those problems.You need to understand the data in order to properly design it.
3. I already have a Symfony app that I took on and am having a hard time visualizing the whole application. Will this help break down the data objects in the application if it is already written?
   • Yes, it will. In one of the examples below I examine this very thing using the Jobeet tutorial. And it is quite impressive in that vein
4. Isn’t this just another tool that requires me learning more about how this tools works and wasting more time on this instead of doing actual coding?
   • Well, I will never tell anyone how to code, nor how to do things. But learning new tools is never a bad thing. Sure it takes time to learn, and it takes patience to learn how to use any new tool. I guess the follow up question to this one is: Do you really want to spend your time coding great projects, or fixing bugs the majority of time because you failed to plan?

OK, I am sure there is more questions. However, let’s go through the actual product. One of the things I like about this product, is the ability to pull in Symfony (or non framework ORM) projects, and the application is deciphered. I used the standard Jobeet tutorial from Symfony, and imported the application. And it gave me the following.

It was great. I could immediately see the relationships in the user object data, and the job object data. But now was the real test. I decided that I needed to add an object for the job object. This was for the benefits. So I added “jobeet_benefits” with an “id”, “benefits_title”, and “description”. I added the association over to the “jobeet_job” object. The user interface is done really well and was easy to add. So that passed. What about code generation. Would it update the code properly? And it was successful to write this over to the <doc root>/sym/config/schema.yml

Now all I need to do is run my propel scripts again, rebuild all the objects, build the DB, and the insert the fixtures and update any forms that were altered to include the new fields. And it works great. This is a great way to visually build, append, and maintain Symfony apps. It also works just as well with non framework Propel applications. I did not test this on Doctrine.

The downside to this though: no CakePHP import. I tried to do a few different ways to import a CakePHP application, and nothing worked. So that was a definite question mark when it comes to CakePHP applications. But since we can not open an existing one, let’s test the new project in CakePHP.

I just opened up the application and started to create a simple application that had a member class, that connected to a profile class. And each member can make a post. I created the objects based on the CakePHP naming convention. It created a good visual of how the entities relate to each other. and then I did an export to see what data would be created. This is the directory structure it created:

-app
 -models
  -base
     basemembers.php
     baseposts.php
     baseprofiles.php
   members.php
   posts.php
   profiles.php
  schema.module.xml

I was interested in why it created a base file set. And I am sure it is because if you put custom code in the model, and then need to update the ORM, it will not overwrite your custom code. So I decided I would test that. I put in a little function that did nothing in the posts.php file. I then went in to change the posts object to add a post title to the object. Then I exported the items again. And the custom function exists! This is a great thing for exporting the model changes. This is why the ORM Designer creates a Base file for the models, to keep custom code from being over-written.

Another good thing, and also a little bit of an area of opportunity, is the CakePHP validation. It makes validation of each field very easy. It provides a great way for each field to have a specific validation rule or rules. However, each validation rule has the same fields available which can be a little confusing to those who may not understand each validation rule. I understand why it is that way, it can just cause some issues for the more inexperienced CakePHP developer.

Now, a quick run down of what I liked about this and what I felt could be a little different:
Pros

• Cost: 99 Euros, approx 127 USD, not as expensive as other tools
• Ability to import Symfony and other Propel/Doctrine projects and be able to quickly get a feel for what the application holds
• In the Windows model it is easy to use, windows and sheets are good, and wizards are very simple to go through
• Very quickly learn time to use, design and export
• Can do a simple job, or get to more complex tasks
• Configuration of the application is easy, straightforward
• CakePHP validation made a little easier to understand
• Customization of associations, entities and fields
• Color coded models/modules makes it easier to distinguish separate modules, which is really good for the 3rd level normalized databases that grow in enterprise applications
• Does not require processor intensive and draining resources on a Windows machine
• Support is off the charts. The ORM Designer team really owns this product and really cares, so they provide some of the best support for the product.

Items that can be “areas of opportunity”

• There is no native support for Mac and Linux. Sure it works with Wine, but I just prefer my Mac apps to work natively with OSX instead of having to install more 3rd party software just to get some other 3rd party software running. Just my preference though
• The sheets to open projects, add projects, save, etc all seem to differ. I am more of a streamline type, if more than one “file” object sheet is needed, then make them all look the same
• Does not import existing CakePHP applications, which can cause some slow down if you start to use this tool after the application is already under way
• CakePHP validation seems to contain all options for every type of validation, and for someone who may not understand the details of all the different validation options, it can be a concern when it builds

Overall, this seems like a good tool. I am sure other people will find nuances as they start to use it more in the everyday world of developing. It seems like a good tool to use to help design databases. Even if the export is never done for the models/code in any framework/ORM, this is a great tool to use to help plan DBs out, view the relationships, associations.

To find out more information:
ORM Designer Main page
Documentation and Tutorials
ORM Designer on Twitter
ORM Designer Facebook
Blog ORM Designer

************** EDIT 06 Sep 2010 **************
From the ORM-Designer Team:
We‘re currently working on an automated import from database servers (MySQL, SQLServer and next major DB systems). This feature will enable users to easily import the model from their existing CakePHP (and other) projects.
(This is a huge one for the CakePHP community and one I am looking forward to)

Recently we added a new feature for CakePHP export, but this feature could be little hidden for new users and we want to propagate it more on our web in future. Besides the model files you can export also a DB structure to schema.php file which is useful for database migration.
More about this feature is on our blog.
(This is another huge win for the CakePHP community)