If you aren’t already hip to the idea of Active Record, it is the concept of tightly coupling records in a database to an object in whatever language you are working with. This allows you to conceptualize and produce your application in a very similar manor. For example, when you want to make a Blog, you think about A Blog, Comments, Categories, and Tags (to name a few). Object Oriented Design teaches us to think of these as object, requiring you to give them attributes and methods, while UML takes it a step further and defines a system for engineering the software with OOD – linking the objects together to form cohesive functionalities.
Since beginning my masters in Computer Science two years ago, I’ve been on a constant quest for a framework that best suites my needs: fast production, systematic, object oriented, and scalable. Some front-runners may scream “Rails!”, which I tried – but lost interest, mainly because I spent more time trying to play by DHH’s rules then actually developing. (Let me be very clear, I am not knocking Rails or DDH, the framework is brilliant and the community and support is booming, but it just wasn’t for me … maybe in the future.) So I searched for PHP frameworks: CakePHP, Zend, and Symfony were all overkill for me, a lot of bloat that I didn’t need (once again, not “unnecessary”, just “I didn’t need” … the aformentioned PHP framework are also awesome and I applaud them all.) It wasn’t long until I realized that I am only going to be happy if I make my own, and so I did.
Now, any developer worth his salt has an arsenal of code that he reuses, that’s a given. I’m no different: I’ve developed a library specifically suited for my needs consisting of mainly classes, common and layout functions, and random configurations. One key feature that they all rely on is my MySQL and DB class. Together, they act as a sort of abstraction layer to a database. For example, if I did
it would loop through the data, clean it as needed, create and INSERT statement, and return me the results. It worked okay, but it wasn’t crazy flexible. Joins were nearly impossible, so I had to flank my own system by writing straight SQL statements. That was okay, though, because my queries we’re normally very straight forward due to the domains of the projects I’ve worked on. That was, however, until further studying into software engineering opened my eyes to an ugly issue that I find in my code, and in many others.
The issue is as follows: OOD says an object is to be fine-tuned so that it can handle itself the best that it can, it doesn’t know anything about any other object, unless you tell it to. If you need more access, you need more objects. Relational databases, on the other hand, want you to fine-tune your queries so that one statement can grab you all the info you need. So to recap, OOD wants multiple accesses to objects of limited information, and RDBs want a single access to an object of unlimited information. Two necessary components of your app with two differing ideologies.
With a little thought, it becomes apartent that while multiple hits to he DB is really bad, breaking OOD patterns is just wrong. So while researching how to develop an Object Relational Mapper to keep your code OO while keeping effecient DB access in mind, the good folks in #php kept referring me to Doctrine.
Doctrine is an ORM built on top of a database abstraction layer. After extremely thourough investingation, it proves to be an invaluable resource neccesary for any OOD trying to build the most effecient application possible. Doctrine comes complete with a powerful active record class system with an eligent, fully documented API, a database scheme manager, a suite of command-line utilities for various functionalities such as auto-generating models and database tables, a built in fixture system for auto-populating test data, integration for the development of custom test suites, and yes … much more.
Now while these features alone are enough to sell even the most skeptical buyer, what sold me was it’s extremely small footprint and seamless integration with my custom framework. Truth be told, Doctrine took about 20 minutes of reading over the guides to get comfortable with, about 10 minutes to integrate with my existing framework, and now saves hours of code writing. Utilizing PHP5’s object daisy chaining, you can link Doctrine’s lightweight record methods to do in one line what previously took close to 100.
$user = Doctrine::getTable("user")->findByEmail("firstname.lastname@example.org")->toArray();
It doesn’t get much easier than that. Backed by not only a very intuitive API, a well versed documentation, and #doctrine, one of the most helpful and curtious IRC’s I’ve ever worked with. With the development of version 2 in the works, Doctrine is on their way from a being a 3 year old ORM mapper, to becoming an absolute nessecity for any web application powered by PHP.