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.

I hadn't been using Doctrine for a while and decided to pick it up two weeks ago, as we wanted to see if we can implement it for our CMS at our office. So I setup a clean installation of the zend framework (1.11.9) and tried tried to implement Doctrine. The main goal was to see if we can reverse engineer existing databases and then start doing some queries.

There were three things he found in the process that caused a few issues:

• A confusing set of terms and features that weren't explained well enough to know their use
• Getting things like autoloaders working with the Zend Framework to make things work well together
• A potential bug with the "name" property on an object and some automatic namespacing Doctrine tries to do

There are already a lot of resources available on the Internet. I have looked at various configurations, like for example the 'bisna' project from Guilhere Blanco. But I keep saying that it's really difficult and has a steep learning curve. Doctrine 1.2 was really simple. Doctrine 2.x is a lot more difficult to get into.

The Data Mapper pattern is a mechanism for persistence where the application model and the data source have no dependencies between each other. [...] But everytime we talk about the Data Mapper pattern, we assume there is a relational database on the other side of the persistence boundary. We always save objects; we always map them to MySQL or Postgres tables; but it's not mandatory.

He talks about two projects, MongoDb_ODM and CouchDb_ODM, that the Doctrine project is working on to help make working with document-driven databases as simple as the usual ORMs. He includes a brief code snippet showing how the feature will work (hint: a namespace of Document instead of Entity). He lists some of the features - including the usual ORM capabilities, support for collections, cascade of persistence - and where you can get the latest code for it (from github and PEAR

It shouldn't be long until the first alpha version of PHP 5.4 will be released and with it there will be a lot of new features such as array dereferencing and traits to name but a few. What does that mean to the roadmaps of Doctrine and Symfony?

He mentions the experiments that are proposed on the Doctrine project that could be one of the major driving forces behind Doctrine 3. He points out that, as long as Symfony stays non-PHP 5.4-only, users will still have the choice of Doctrine 2 or 3. There are two issues he points out, though, that could cause problems for both projects - the choices Symfony makes in things like its quickstart guide and the DoctrinBundle vs Doctrine3Bundle situation that could come up.

With the release of the first beta approaching fast, our main focus has switched from adding new features to polishing existing ones. [...] Recently, Ryan and I have spent our time tweaking error messages, simplifying the code and the configuration, adding more documentation, and making things more consistent throughout the framework. The goal is to ease the learning curve and make things that people will need on a day to day basis simpler.

The changes they've made include three updates - better Twig error messaging, better configuration error messaging and some helpful changes to the Doctrine configuration to allow for auto-mapping of connections when the traditional one-database setup is used.