When I first started using Doctrine 2 with Zend Framework, I of course Googled around for information about integrating the two. The process is pretty simple and I actually ended up just writing my own Application Resource. However, this is as far as blog posts got and they never got into detail on how to use Doctrine 2 in a practical context, or they promote using the EntityManager directly from the controller, which IMHO is really bad. So I’ll assume you already have the CLI setup and a working EntityManager stored in the Zend_Registry. Another side note, I prefer and recommend the annotations driver over the YAML or XML counterparts.

Time to change your thinking

Initially, it would be easy to misunderstand what an Entity is. At first, I was still viewing them as a class that defined the table structure but this is very wrong, you need to think of them as a persistable class. The other thing we need to sort out is how we use the Doctrine from a Controller. As I previously mentioned, I see a lot of examples that promote this:

<?php

/**
 * Manages articles
 */
class ArticleController extends Zend_Controller_Action
{

    /**
     * @var Doctrine\ORM\EntityManager
     */
    protected $_em;

    /**
     * Get the EntityManager
     */
    public function init()
    {
        // Reg = Bad; use an action helper as a DI container to store/retrieve the EM and pass it to your services
        $this->_em = \Zend_Registry::get('Doctrine/ORM/EntityManager');
    }

    /**
     * Get a list of Articles
     */
    public function listAction()
    {
        $this->view->articles = $this->_em->getRepository('Article\Domain\Entities\Article')->findAll();
    }

    /**
     * Update an Article from POST params
     */
    public function updateAction()
    {
        $article = $this->_em->getRepository('Article\Domain\Entities\Article')->find($this->_getParam('id'));
        $article->setTitle($this->getRequest()->getPost('title'));
        // ... etc (and you would refactor all POST data into a local variable as well)

        $this->_em->persist($article);
        $this->_em->flush();
    }

}

There are three major problems with this:

1. Your controllers will quickly evolve into a fat mess of persistence logic
2. If you want to change from Doctrine to something else (like RedBeanPHP), then your screwed
3. You will likely be duplicating a lot of code when handling persistence.

To eliminate the two above problems, we need to completely decouple our Doctrine code from our controller code and we will do this by adding our own layer between the two frameworks.

Interfacing the problem

The idea is to write plain PHP classes that will serve as our middle man. The key factor is Separation of Concerns, in any situation: your application controllers shouldn’t be directly dealing with your data persistence or in this case the EntityManager. Furthermore, we can now test our domain layer without having to cycle up our entire MVC framework.

I think it’s best to learn by example, so we will create a very basic eCommerce system. We will use the following entities:

<?php

namespace MyApp\Domain\Entity;

// I define a custom Repository class for most entities
/**
 * @Entity(repositoryClass="MyApp\Domain\Repository\ProductRepository")
 */
class Product
{

   /**
    * @Column(type="integer")
    * @Id @GeneratedValue
    */
   private $id;

   /**
    * @Column(type="string")
    */
   private $name;

   /**
    * @Column(type="integer")
    */
   private $price;

   // getters and setters

}

An now a basic service:

<?php

namespace MyApp\Domain\Service;

use Doctrine\ORM\EntityManager;

class ProductService
{

    private $dm;

    public function __construct(EntityManager $dm)
    {
        $this->dm = $dm;
    }

    public function updateProduct(array $data, $id)
    {
        $product = $this->dm->getRepository('MyApp\Domain\Entity\Product')->find($id);

        if(!$product){
            throw new ProductNotFoundException();
        }

        $product->setName($data['name']);
        $product->setPrice($data['price']);

        $this->dm->flush();
    }

}

A fairly basic implementation of updating a product, don’t forget your life could be easier by using Doctrine’s ClassMetadata classes – though use it wisely. One thing to watch out for is your naming consistency with methods, (i.e. create v. add, delete v. remove, etc), I like to follow CRUD so I can always remember. Now working with your domain and persistence layer is much more hassle free from your controllers:

<?php

namespace MyApp\Admin\Catalog;

use MyApp\Library\Controllers\BackEndController

public function ProductController extends BackEndController
{

	public function updateAction()
	{
		$product = $this->getRequest()->getPost();

		// insert form validation and get filtered values (into $filteredProduct)

		$productService = new \MyApp\Domain\ProductService($this->resources()->entityManager);
		$productService->updateProduct($filteredProduct, $filteredProduct['id']);
	}

}

So for my latest application I’ve decided I whip up a custom Form class and a GenericError decorator.

To start off, our custom Form class will need somewhere to store errors and getters/setters:

/**
 * Custom Form Class
 */
class Cob_Form extends Zend_Form
{

	/**
	 * Stores generic errors
	 */
    protected $_genericErrors = array();

	/**
	 * Add a single generic error
	 *
	 * @param string $error Generic error message
	 * @return Cob_Form
	 */
    public function addGenericError($error)
    {
        $this->_genericErrors[] = $error;
        return $this;
    }

	/**
	 * Append an array of generic errors
	 *
	 * @param array $errors Generic error messages
	 * @return Cob_Form
	 */
    public function addGenericErrors(array $errors)
    {
        $this->_genericErrors = array_merge($this->_genericErrors, $errors);
        return $this;
    }

	/**
	 * Set the generic errors
	 *
	 * @param array $errors Generic error messages
	 * @return Cob_Form
	 */
    public function setGenericErrors(array $errors)
    {
        $this->_genericErrors = $errors;
        return $this;
    }

	/**
	 * Set generic error
	 *
	 * @param array $errors Generic error message
	 * @return Cob_Form
	 */
    public function setGenericError($error)
    {
        $this->_genericErrors = array($error);
        return $this;
    }

    /**
 	 * Retrieve all generic error messages
 	 *
	 * @return array
	 */
    public function getGenericErrors()
    {
        return $this->_genericErrors;
    }

	/**
	 * Returns true is any errors messages have been added
	 *
	 * @return bool
	 */
    public function hasGenericErrors()
    {
        return count($this->_genericErrors) > 0;
    }

}

The above is nothing special, but I’ve added method chaining with the setters to maintain consistent API.

The next step is to write our decorator so the form will automatically render the errors if any are set.

<?php

/**
 * Zend_Form decorator to render generic errors
 *
 * @author Andrew Cobby
 */
class Cob_Form_Decorator_GenericErrors extends Zend_Form_Decorator_Abstract
{

	/**
	 * Render generic errors
	 *
	 * @param string $content
	 * @return string
	 */
	public function render($content = '')
	{
		$form = $this->getElement();
        $view    = $form->getView();

		if(!($form instanceof Cob_Form)){
			throw Zend_Form_Exception("You can only use the GenericErrors decorator with forms that subclass Cob_Form");
		}

        if (null === $view) {
            return $content;
        }

        $errors = $form->getGenericErrors();
        if (empty($errors)) {
            return $content;
        }

        $separator = $this->getSeparator();
        $placement = $this->getPlacement();
        $errors    = $view->formErrors($errors, $this->getOptions());

        switch ($placement) {
            case self::APPEND:
                return $content . $separator . $errors;
            case self::PREPEND:
                return $errors . $separator . $content;
        }
	}

}

The above decorator is almost an exact copy of the existing Errors decorator, but I had to tweak it a bit.

site/
  library/
    Cob/
      Controller/
        Action/
          HelperBroker.php
          Helper/
            Myhelper.php
            HelperAbstract.php

HelperBroker.php

<?php

namespace Cob\Controller\Action;

use \Zend_Controller_Action_HelperBroker;

/**
 * Custom implementation of the HelperBroker to provide namespace support
 *
 * @author Andrew Cobby
 */

class HelperBroker extends Zend_Controller_Action_HelperBroker {

    /**
     * Add a namespace prefix (works the same as Zend_Helper_BrokerBroker::addPrefix()
     *
     * @param string $prefix Namespace prefix
     */
    static public function addNamespacePrefix($prefix)
    {
        $prefix = rtrim($prefix, '\\') . '\\';
        $path = str_replace('\\', DIRECTORY_SEPARATOR, $prefix);
        $path = rtrim($path, '/');
        self::getPluginLoader()->addPrefixPath($prefix, $path);
    }

    /**
     * Adds an array of helpers
     *
     * @param array $helpers Helpers
     */
    static public function addHelpers(array $helpers)
    {
        foreach($helpers as $helper){
            parent::addHelper($helper);
        }
    }

}

HelperAbstract.php

<?php

namespace Cob\Controller\Action\Helper;

use \Zend_Controller_Action_Helper_Abstract;

/**
 * Abstract helper for namespaced action helpers
 *
 * @author Andrew Cobby
 */

class HelperAbstract extends Zend_Controller_Action_Helper_Abstract
{

    /**
     * Fix to get the correct helper name (Overrides Zend_Controller_Action_HelperAbstract::getName)
     *
     * @return string
     */
    public function getName()
    {
        $className = get_class($this);
        if(strpos($className, '\\') !== false){
            $helperName = strrchr($className, '\\');
            return ltrim($helperName, '\\');
        }elseif(strpos($className, '_') !== false){
            $helperName = strrchr($className, '_');
            return ltrim($className, '_');
        }else{
            return $className;
        }
    }

}

Myhelper.php

<?php

namespace Cob\Controller\Action\Helper;

/**
 * Example helper that uses namespaces
 *
 * @author Andrew Cobby
 */

class Myhelper extends HelperAbstract
{

    public function direct()
    {
        return 'Namespaces are cool!!';
    }

}

Before you starting using this, you will need to add your namespace prefix in our new HelperBroker:

<?php

namespace Cob\Controller;

use \Zend_Controller_Action;
use \Cob\Controller\Action\HelperBroker;

class Action extends Zend_Controller_Action
{

    public function preDispatch()
    {
        HelperBroker::addNamespacePrefix('Cob\Controller\Action\Helper\\'); // remember 2 trailing slashes to fix the escaping
        $coolio = $this->_helper->Myhelper(); // calling a helper is still the same
    }
}

As you can see, the only real part of the compatibility issue is overriding HelperAbstract::getName(), the methods in HelperBroker are more just for convenience.
Hope this helps!