phpBB Weekly

Session: Doctrine 2 by Jonathan Wage
Date/Time: Friday 8/20 at 2:00-2:45 PM

This post contains my rough crib-notes from this presentation at Libertyvasion 2010. The post has not been proof-read for spelling, grammar, or accuracy.

Jonathan Wage, has been a web developer for over a decade. An Open Source Evangelist and published author, contributes to Doctrine and Symfony, and is employed by Sensio Labs.

Doctrine started on April 13, 2006 (first commit), and first stable version released September 1, 2008. It was one of the first Object Relational Mapper (ORM) implementations for PHP. Version 1.0, maintained until 3/1/10, has been integrated with a number of popular frameworks, including Symfony.

What’s an Object Relational Mapper?
Shows the definition coming straight off of Wikipedia. Essentially it creates a virtual object database for interacting between a database and an object-oriented programming language, such as PHP.

Jonathan is showing off how Doctrine 1 worked, but pointing out some problems: The domain is bound to the persistence layer, the complexity of domain entities is limited by the persistence layer, $model->save() is a bottle neck for persisting large numbers of objects, and testing your domain model requires mocking the persistence layer.

Doctrine 2 aims to solve a lot of those problems. No more base class to extend; you’re simply working with regular PHP objects, classes, and properties. Base tables & domain entities no longer bound to the persistence layer. Can specify mapping information with XML, YAML, or DocBlock Annotations in PHP, and Jonathan explains the advantages & disadvantages of each. XML is his preferred method.

Transparent Persistence is the #1 rule followed in Doctrine 2. No dependencies to the persistence layer should exist, meaning that testing can happen directly with PHPUnit. Doctrine can persist an object simply by passing an instantiated object to a persist() method.

Why Transparency?
* Better performance
* Easier to cache regular PHP objects that are not bound to the persistence layer
* Easier to test your domain, no mocking required
* Ultimate flexibility over the complexity of your domain entities without being imposed on by your persistence layer

Doctrine 1 benefited greatly from using PHP 5.3 in terms of speed & memory usage in testing. Doctrine 2 is about 2-3 times faster than Doctrine 1. Doctrine 2 also fully uses & supports namespaces, making it much easier to combine libraries by virtually eliminating naming conflicts. Doctrine 2 (& Symfony 2) also fully supports PHP 5.3 Interoperability Standards (link coming).

Doctrine code is divided into a few different packages:
* Doctrine\Common — Common functionality shared across packages, Events, Annotations Library, Lexer Parser for the Doctrine Query Language (DQL), Other various convenience tools
* Doctrine\DBAL — Relational database abstraction layer (MySQL, SQLite, PostgreSQL, Oracle, MsSQL), can also write drivers for other databases — DBAL is Standalone, can be used without the ORM
* Schema Manager — Issue DDL statements through intuitive APIs, introspect your database scheme as well
* Doctrine\ORM (the “killer feature” of Doctrine) — Built on top of the DBAL

The architecture of Doctrine 2:
* The ObjectManager: EntityManager and DocumentManager
* Object States: Objects can be New, Managed, Detached, or Removed

The Doctrine Query Language (DQL) is the killer ORM feature. It’s similar to SQL, and is a proprietary object query language. Instead of working with tables and columns, you’re working with objects and fields. Doctrine 2 parses it with a recursive descent parser (giving you good parse errors if you mess up). Doctrine constructs an abstract syntax table (AST) when parsing the DQL query, which generates the full SQL query for the relational database being used. The DQL parser also has every piece of the language represented by its own class in its own file, so it’s easy to discover and learn the language (i.e. OrderByClause.php, SelectClause.php, etc.). Parsing of the DQL is also cached to improve performance.

Jonathan shows and explains a DQL query, which looks very much like SQL, however he’s pointing out how doing a LEFT JOIN is easier because you don’t need to explain in the query how to map the two together, since Doctrine has already mapped them. Doctrine also has a result cache method so that the results of the query are stored in a cache driver instead of the database. Events can be set up to automatically clear the cache when the data gets changed.

The Doctrine features are tightly integrated with Symfony 2 — simply enabling the DBAL and ORM services in the Symfony configuration is all that needs to happen.

In Conclusion: Why use an ORM?
* Encapsulation of your domain logic in one place
* This improves Maintainability
* Testability is improved because of this maintainability
* Portability for portable & thin application controller code and fat models