For my project I decided to use the Doctrine 2 ORM to manage my data layer. We also use this at work, so the biggest reason I chose this was to be able to learn more about Doctrine to help me in my job. But this decision also makes sense for my project because my entity relationships will likely be fairly straightforward for the most part and using an ORM will allow me to make a lot of progress very quickly without (I hope) causing me lots of trouble later on.

His handy wrapper (Data Manager) makes it simpler to perform the flush and still take transactions into consideration. His simple class includes "flush", "commit" and "startTransaction" methods that don't actually perform the flush until the commit is called.

Our first idea, and it was not that bad, Drupal does just the same, was to have a database table with the common fields, a field containing the type of item (it's either an event or a blog post) and a data field where we serialized the corresponding PHP object. This approach was ok until we had to filter or search LabLog items based on fields that were contained in the serialized data.

To resolve the issue they turned to multiple table inheritance, relating the LabLogItem to both a BlogPost and Event. They also show how it could be modeled with a single table, but opt for the multiple method. Included in the post is the Doctrine-based code showing how to create the parent entity for the LabLogItem and the two child entities for the blog post and event. There's also a brief snippet showing how to use them with the EntityManager.

In the PHP world, probably the Doctrine ODM for MongoDB is the most successful. This followes to the opularity of Mongo, which is a transitional product between SQL and NoSQL, still based on some relational concepts like queries. [...] The case for an ODM over a plain Mongo connection object is easy to make: you will still be able to use objects with proper encapsulation (like private fields and associations) and behavior (many methods) instead of extracting just a JSON package from your database.

He briefly mentions that the PECL extension for Mongo needs to be installed prior to trying out any of the examples. His first example shows how to create a DocumentManager (similar to the normal EntityManager for those familiar with Doctrine). He also shows an integration with the ORM and shares some of the findings he's made when it comes to versioning the resources (hint: annotations are your friend).

One of the pain points for me though has been in getting Doctrine setup with PHPUnit for testing. One of the main Doctrine contributors, Benjamin Beberlei, has written a package called DoctrineExtensions which amongst other things adds a class called DoctrineExtensionsPHPUnitOrmTestCase which extends PHPUnit's DbUnit database test case class. This all works well in principle but hits a major snag in reality: MySQL doesn't allow InnoDb tables with foreign keys to be truncated. PHUnit's database extension truncates the database tables before each test run and inserts a fresh set of data to work with.

To work around this issue Jeremy by porting over a method posted by Mike Lively over to Doctrine as a custom "MySQLTruncate" class (code included in the post). He also includes some sample code showing it in use - a basic ORM test case that calls the truncate method when its set up.

This article will show how we can develop software in php with a nifty design and architecture, and very much like other languages like java, using an ORM and an AOP, DI, Events container. I will assume you've read (or at least took a quick look) at this article that explains the tree layout used throughout the code, and that you have some basic knowledge of Doctrine2 and used it before on your own.

He starts with the result - an easy to use, self-contained (and decoupled) system for accessing the Doctrine2 instance. It's event-driven and uses Aspect-oriented programming to mange interactions between components (or as he calls them "beans"). Code is included for the entire process for a logger, the User entity, entity manager, user repository and transactional aspect. You can find the complete source for his example on his github account.

This post will describe a way to integrate Zend Framework 1 and Pimple. A complete working version of the code is available on github. Thankfully, Zend Framework 2 features its own Dependency Injection Container. Happy days. Still, if you're not prepared to wait, you may find this useful.

He shows how to add a resource plugin into the Pimple container - an entity manager that's part of Doctrine. He creates his controller, pulling the manager from the Pimple container and includes a unit test for the controller too (using PHPUnit, but he also suggests Mockery).

Ready to take your PHP skills to the next level? In this new "From Scratch" series, we'll focus exclusively on Zend Framework, a full-stack PHP framework created by Zend Technologies. This second tutorial on our series is entitled "Models and Integrating Doctrine ORM".

They continue on from their previous tutorial to talk about what models are (with an example involving "bankers"). They also show how to use the Zend Framework "zf" command line tool to configure your database settings, set up the tables and download/bootstrap the Doctrine code. The include the code to create some simple models and how to use them to create and update records in your database. You can grab all of the sample code for their examples from The Next Social's github repository.

Version 2.0 seeks to improve upon the current release in a number of ways, focusing on making it easier to get started using the framework, improving performance, and fully embracing the latest PHP language enhancements made available to version 5.3. [...] Although the official release won't be out for several more months, it never hurts to take an early look at what the future holds for a technology used by countless PHP developers around the globe. In this article I'll present a meandering introduction to the key version 2.0 features that I find particularly compelling.

He starts with a brief tutorial on getting the latest version of ZF2 from the git repository and creating basic project. The changes in the framework have fallen into a "rewrite only where it makes sense" mentality and changes have really only been made transparently to the backend or as new features/components like module management and Doctrine 2 integration. He also points out a few resources you can use to keep up to date on the latest from the framework including the changelog, mailing list and the ZF2 blog.

The materials teach how to use prepared statements, how to escape and write secure stored procedures. Many PHP projects are covered - PDO, Propel, Doctrine, Zend Framework and MDB2. Multiple gotchas and caveats are included. I discuss why escaping is usually the wrong choice, which practices to avoid or follow and how stored procedures sometimes offer no protection at all.

The presentation (as posted to Slideshare) starts with some of the basics - what SQL injection is and an example of how it could be used to bypass security. He covers how to use prepared statements in each of the technologies (with code snippets), methods for escaping data and how to create stored procedures that are protected from the same threats.

In principle, the combination of Zend Framework with Doctrine is not too difficult. But first let's talk about the preparations. According to the author of Zend Framework, the default file structure of project can be a bit more optimal.

They start by describing this optimized file structure (moving the models out of the modules and into the library) and what you'll need to change in Doctrine's configuration to make this work. The post also includes examples of what the larger config should look like when the changes are made. They show how to extend the default Doctrine CLI tool to make a custom "sandbox" instance and show some tuning you can do on the Zend Framework side so it can optimally work with the new models.