If you are following twitter (you can find me there also) or any other social network, you might have noticed that there is a huge interest in Doctrine and Zend Framework integration. Since I’ve been using these libraries for quite a while now, so I’m going to explain some best practices and ways you can do that.
History
To start with, in my opinion, Zend Framework never had a proper M from MVC. It was quite common to use Zend_Db_Table as base models class, but it was simply not practical. When you start dealing with relations and hierarchical data types it starts to get really tricky, because simply Zend_Db_Table doesn’t provide an extensive enough functionality.
So half a year ago Zend Framework developers started to look for better solutions. Quite obvious one was to start implementing their own Domain layer. You can find quite a few different implementations of that in blogosphere, and I chose this path also. However, after quite some time of developing my own code I realized that it’s simply not a right thing to do – I’m expected to deliver a product and I was “wasting” way too much time tweaking, testing, extending etc. my domain model code.
So about 3-4 months ago I completely switched to Doctrine. After evaluating possible solutions I decided to stay with Doctrine for a long time. I don’t know any other solution coming, I definitely don’t want (mainly because I don’t have time) to invest on creating my own library and Doctrine is simply awesome when you get used to it. After all this time I can say that it was a right call – Doctrine is on a way to being officially supported in Zend Framework (Symfony has it right now) and with Doctrine 2.0 (you can see a short presentation of its new features right here) it will be just a perfect tools combination. I would very much agree with Giorgio that:
Thus, Doctrine 2 is going to become the first production-ready Orm for php and to be favored with seamless integration in both Zend Framework and Symfony.
Benefits
Some time ago I was actually involved in making a decision of choosing Doctrine over other libraries (main Zend Framework components) as part of my work, so here I’m going to outline some points which made that decision easier.
Relations. I keep repeating this term every time I speak about Doctrine (or ORM’s in general), but for me it’s a key factor in writing code fast. Quick example: let’s image that our application consists of Order which has a list of Items where Item is Product and price, quantity information. Code for this situation:
$order = new Order(); $item = new OrderItem(); $item->Product = $product; // product object from somewhere $item->quantity = 10; $item->price = 9.99; $order->Items->add($item); $order->save();
This is how much code I need to write myself. I’m going to show more examples in the future posts, but because Doctrine is ORM (object relation mapper) all the hierarchical structure of your application data becomes very easy to work with.
What is more, Doctrine can generate all the model classes by itself. Now that’s a treasure! Just specify database connection in the config file, open up a terminal and run:
php doctrine-cli.php generate-models-db
In a few seconds all schema information is retrieved from the actual database and all the classes are created. My biggest project so far with Doctrine was worth more than 10′000 lines of models code. I don’t know how to count the time it saved and despite a few minor bugs in Doctrine library it worked exactly as we wanted.
I can list things I like about it for hours probably, so I’m going to finish this list with the future I consider to be a very big time saver. This feature is dynamics of models: inheritance and behaviors. Inheritance makes your objects have different classes even though they could be a same table (with for example type_id). All the work needed to handle the actual schema is done in background.
Behaviors work in the same way – one line of code and a model becomes physically undeletable (called soft-delete) or has a separate table to save revisions. Behaviors are very similar to decorators in Zend_Form for example – they are small classes which can be added to the main class to extend its functionality. So in the end your mode could have all sorts of different functionality depending on how you “decorate” it.
What’s next?
I only wrote a few examples how great Doctrine actually is today, but you can expect a lot more. Especially in Zend Framework code side: application.ini settings, application resource to setup auto-loading, script to generate Zend Framework compatible models, testing Doctrine models and much more. I’m also involved in a work group making Doctrine and Zend Framework integration possible so you can expect great things to come (first proposal here).
If you have been following me on twitter you might have noticed that I tweet a lot of interesting material on both Zend Framework, Doctrine and general PHP so I would recommend following me there or subscribing to the RSS feed. I haven’t been writing for a while now, but I will try as hard as I can to change it and write much more frequently – during past months I tried a lot of cool stuff which I would love to talk about.
All parts:
- Zend Framework and Doctrine. Part 1
- Zend Framework and Doctrine. Part 2
- Zend Framework and Doctrine. Part 3
dave
