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:
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.
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.
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
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:
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.
************** 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)