In Zend_Db, after configuring your database, in order for arabic / persian / non-ascii characters to persist properly, you need to configure the character set:

 
// setup database
$db = Zend_Db::factory($config->db->adapter, $config_values);
// for Unicode support
$db->query("SET NAMES 'utf8'");
Zend_Db_Table::setDefaultAdapter($db);
 

In Doctrine, a similar declaration is needed to setup the right character set. These lines would be in the config.php file included in the sample project, or whenever you initialize your Doctrine_Manager:

 
$connection = Doctrine_Manager::connection(DB_PATH);
$connection->setCharset('UTF8');
 

The equivalent Doctrine code is almost as elegant. Here's an excellent example of when objects abstract you from the nitty-gritty string parsing code that would be required to do time-stamping in a database:

 
$today = new Zend_Date();
$newPost = new Post();
 
$newPost->title = 'posting for ' . $today->get(Zend_Date::TIME_MEDIUM);
$newPost->createdAt = $today->get(Zend_Date::W3C);
$newPost->save();
 

Zend_Date::W3C returns a W3C compliant timestamp, which the Doctrine Model then passes to the underlying persistence layer.

Assuming that you had a UnitOfWork class handling your persistence, you could add createdAt to all of the YAML models, and have every record stamped with updatedAt and createdAt without changing any higher level code.

Why Bother With UpdatedAt and CreatedAt?

having these two columns in a table can save tremendous amounts of time sorting out concurrency issues. They also allow you to do some very primitive reporting on your data at no cost to adding complexity to the rest of your application.

My Doctrine Model was configured using a YAML file:

 
Post:
  tableName: post
  columns:
    id:
      primary: true
      autoincrement: true
      type: integer(4)
    createdAt: date
    title: string(255)
 

Then it's just a matter of running './doctrine rebuild-db' from the command line from the Doctrine directory and it create's the PHP classes and prepares the database columns.

Using Zend_Date, you can easily do date comparisons, generate different date formats, do complex date querying and so on without having to get into the string / number manipulations.

According to Evans' Domain-Driven-Design book, a Repository depends on a Unit of Work.

Why Bother Using A Unit of Work?

The Unit of Work is an enterprise design pattern that facilitates the persistence of many objects across a single or several data sources. It’s helpful to think of the Unit of Work as a way of putting everything that you would want to update, insert and delete into one bag before sending it to the database.
Functionally, the Unit of Work simplifies transactional requests and helps mitigate concurrency issues on multi-user systems.

I wrote a Unit of Work that depends on Doctrine. Assuming we have a Project model with a name property, the consuming class can perform operations like so:

 
$t = Doctrine::getTable('Project');
$lastProjects = $t->findByName('new project');
 
$unitOfWork = new UnitOfWork();
// prepare an UPDATE
    $lastProjects[0]->username = 'old project';
    $unitOfWork->RegisterModelForCreateOrUpdate($lastProjects[0]);
 
// prepare a CREATE
    $project = new Project();
    $project->name = 'new project name';
 
    $unitOfWork->RegisterModelForCreateOrUpdate($project);
 
// prepare a DELETE
    $unitOfWork->RegisterModelForDelete($lastProjects[3]);
 
// perform the transaction
$unitOfWork->CommitAll();
 

A commit already leverages the existing Doctrine connection and handles the transaction for you, ensuring that the Unit of Work either commits, or throws an Exception.

The UnitOfWork is also an excellent place to include logging code or event additional column data (such as UpdatedAt and UpdatedBy which might exist in all Doctrine models for concurrency / logging purposes.)

I haven't found a better way of doing object-comparison in PHP arrays, however I've pulled out that code into existsInCollections() if anyone has any ideas.

 
 
class UnitOfWork {
 
	/**
	 * Collection of models to be persisted
	 *
	 * @var array Doctrine_Record
	 */
	protected $createOrUpdateCollection = array();
 
	/**
	 * Collection of models to be persisted
	 *
	 * @var array Doctrine_Record
	 */
	protected $deleteCollection = array();
 
	/**
	 * Add a model object to the create collection
	 *
	 * @param Doctrine_Record $model
	 */
	public function RegisterModelForCreateOrUpdate($model)
	{
		// code to check to see if the model exists already
        if ($this->existsInCollections($model))
		    throw new Exception('model already in another collection for this transaction');
 
		// no? add it
			$this->createOrUpdateCollection[] = $model;
	}
 
	/**
	 * Add a model object to the delete collection
	 *
	 * @param Doctrine_Record $model
	 */
	public function RegisterModelForDelete($model)
	{
		// code to check to see if the model exists already
		    if ($this->existsInCollections($model))
    		    throw new Exception('model already in another collection for this transaction');
 
		// no? add it
			$this->deleteCollection[] = $model;
 
	}
 
	/**
	 * Clear the Unit of Work
	 *
	 */
	public function ClearAll()
	{
		$this->deleteCollection = array();
		$this->createOrUpdateCollection = array();
	}
 
	/**
	 * Perform a Commit and clear the Unit Of Work. Throw an Exception if it fails and roll back.
	 *
	 */
	public function CommitAll()
	{
    	$manager = Doctrine_Manager::getInstance();
    	$conn = array_pop($manager->getConnections()); 
 
    	try {
            $conn->beginTransaction();
 
            $this->performCreatesOrUpdates($conn);
            $this->performDeletes($conn);
 
            $conn->commit();
    	}
    	catch(Doctrine_Exception $e)
    	{
    	    $conn->rollback();
        }	    
 
        $this->ClearAll();
	}
 
	private function performCreatesOrUpdates($conn)
	{
	    foreach ($this->createOrUpdateCollection as $model)
			$model->save($conn);
 
	}
 
	private function performDeletes($conn)
	{
		foreach ($this->deleteCollection as $model)
			$model->delete($conn);
	}
 
	private function existsInCollections($model)
	{
 
	   foreach ($this->createOrUpdateCollection as $m)
	   {
	        if ($model->__toString() == $m->__toString())
	            return true;
	   }
 
	   foreach ($this->deleteCollection as $m)
	   {
	        if ($model->__toString() == $m->__toString())
	            return true;
	   }
 
	   return false;
	}
 
}
 

The Doctrine Documentation looks pretty solid and Ruben Savanne wrote a great article about integrating Doctrine into a Zend Framework project. I wholeheartedly agree with his statement that Zend_Db is a little too low level for 90% of tasks that application developers are aiming to accomplish. With a simple YAML configuration, Doctrine promises to generate the necessary classes and even your database schema. These two features are a must if you want to be able to model your database on the fly and run unit tests against a clean schema without writing a complex setup harness.

My only concern is the lack of any obvious enterprise support, regardless this library is worth looking at as an alternative to Zend_Db.