06.12. Doctrine 2 - Zend Framework Integration
In yesterday's article of our advent calendar, we explained the concepts underlying Doctrine 2. In today's article, we want to use that knowledge and create a simple Zend Framework (ZF) application that uses Doctrine 2 to persist its business objects.
While explaining how to integrate Doctrine 2 into Zend Framework, we will create a generic sandbox that can be used for future projects building up on these technologies.
Setting up a ZF project with Doctrine 2
Since this article is not about how to setup a ZF project, the following steps will require you to have a clean but working project with
the usual folder structure.
To use Doctrine 2 you will have to get a copy of its source code first. You can get one either from the project's website or by cloning the git repository. In my opinion, downloading the source package from the website is a lot easier (you don't have to take care of all the project's git submodules etc.). So download and extract the archive into a temporary directory. After that, move the folder Doctrine from the archive's root into the library of your new ZF application. Now, your project structure should look like this:
The first thing that will occur to you if you look at the Doctrine 2 source code is that 100% of the code is
namespaced (for a (German) introduction to namespaces have a look at the article "PHP 5.3 Features in Real Life" from a colleague of mine). This is pretty nice for people who are not scared of new
language constructs but for many people that are using ZF it might look odd at first. I am sure that you will get familiar with the syntax
differences really fast, but ZF (1) does not - because it does support real namespacing yet (however this will change with version 2).
Therefore we have to do some additional work that enables us to autoload classes that reside in namespaces. Luckily, Doctrine 2 comes with a neat set of helper classes bundled in the project Doctrine Common which also includes a class loader that fulfills our needs. The class loader is called Doctrine\Common\ClassLoader and is really easy to use:
This code snippet creates and registers a new class loader that looks for classes in the namespace Doctrine. These classes should be placed in a folder called Doctrine which is part of the current include path. Every namespace separator will be transformed into a directory separator when looking for the classes, so make sure to keep your class-, namespace-, file- and folder-names in sync!
I recommend putting the initialization of the class loader into your application's bootstrap class because this way it can be used for cli scripts, too. As you might have seen, there are several packages inside the Doctrine folder that we placed in your library. The folders ORM, DBAL and Common contain the Doctrine 2 classes required by the framework. The fourth folder Symfony contains some classes borrowed from the Symfony2 framework. To load all these classes, we have to initialize multiple class loaders:
The initialization of the loaders responsible for Symfony2 and entity classes requires a second argument, that indicates the directory in which the classes of the namespaces can be found. If you do not provide this argument, the class loader just looks in the directories of your include path for folder names matching the given namespace.
Creating the Entity Manager
The next thing we will do is creating an entity manager. To do so, we have to initialize a configuration object (of the type Doctrine\ORM\Configuration) and pass it to the entity manager. Since we want to create a project that can be configured ea
Truncated by Planet PHP, read more at the original (another 4051 bytes)