In a recent post Marcelo Gornstein takes a look at using dependency injection with Doctrine2 using his Ding container.

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.

DevShed concludes their three-part series about building an ORM in PHP with this latest article. It introduces the idea of dependency injection into the mix, showing how it can be used in the relationships between entities.

if you've already read the two installments that precede this one, it's probable that you're familiar with the inner workings of this sample ORM. In those chapters I implemented the ORM's data access and mapping layers, along with a simple domain model. To be frank, the development of this last tier is entirely optional; however, it's useful for demonstrating the ORM's actual functionality in the deployment of a blog program, which naturally will handle some "typical" domain objects, namely blog entries, comments and authors.

They share the code for creating proxy objects and, using a "poor man's dependency injection container" made from a factory method, interfaces and service classes to handle the results.

Continuing on from the first part of their series, DevShed has posted part two of their "Building an ORM in PHP" series. This latest tutorial focuses on domain modeling (and collection handling).

In that first part, I implemented the ORM's data access and mapping layers. And as you'll surely recall, the entire implementation process was pretty straightforward and easy to follow. Of course, in its current state the ORM is still far from a fully-functional structure. We need to add some additional components to it, such as a domain model and the classes responsible for handling collections of entities (remember that the ORM relies heavily on the data mapper pattern to do its business properly).

He stays with his "simple blog" example and shows domain models (based on an abstract entity) for Entries, Comments and Authors. His containers extend the Countable, IteratorAggregate and ArrayAccess interfaces to give them some extra abilities.

On DevShed today there's a new tutorial showing you how to build a basic ORM layer on top of a MySQL database. It includes all the code you'll need (cut&paste-able, not as a download).

Obviously, with so many ORMs at one's disposal for free, it seems pretty pointless to develop a custom one; are we trying to reinvent the wheel? No, of course not. But if you need to create a simple application that performs a few CRUD operations on some related domain objects and don't want to climb the learning curve of a third-party library, then implementing a custom ORM might make sense. There's alos the educational aspect of the process (yes, learning one or two things never hurts).

They start you off with the creation of the "data persistence layer" (an interface first) to connect to the database, building a MySQL-specific one on top of it. Next up is the data mapper layer making things like "fetch by ID" and the insert/update/delete possible. Their simple example doesn't include anything about ORM relationships, though - just fetching simple rows.

In a new post to his blog Jigal Sanders shares some of his experience in working with Doctrine 2.1 in a Zend Framework-based (1.11.9) application for his database interface needs.

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.

On DZone.com today there's a new article from Giorgio Sironi about making the switch from Doctrine 1 to Doctrine 2 and some of what might be involved.

Doctrine 2 is an implementation of the Data Mapper pattern, and does not force your model classes to extend an Active Record, nor to contain details about the relational model like foreign keys. [...] Note that you will have to run your application of PHP 5.3 for Doctrine 2 to work, mainly because of the use of namespaces in it.

He talks about some of the other differences including maintaining PHP classes and the metadata in them rather than just a YAML schema to map to your database. There's also a difference in how to interact directly with the Doctrine engine. Direct access has been replaced with a dependency injection approach.

On the ServerGrove blog there's a new post showing you how to create indexes for your Doctrine ODM documents in a Symfony 2 application.

Creating indexes in NoSQL / Document-based databases is quite different compared to traditional relational databases. Since the former are schema-less (there is no table creation), indexes do not get created when the collection or the document is created or inserted. Here is a quick tip that will create all the indexes defined in your documents when using Symfony 2 and Doctrine ODM for MongoDB. Indexes are a great way to speed up your queries, in fact, it is a crime not to include them in your documents.

Adding the index is as easy as putting a new annotation on the property in its document class (for @Index) and run a bit of code in Symfony to build it out. The two lines you'll need to execute are included in the post.

In his previous post Vic Cherubini introduced his namespaced DataModler ORM class and showed how to create a basic model to work with user information to the database. In this second part he looks at taking those models and saving their contents to the database.

After you have created your Models, it's time to save them to a datastore. DataModeler requires you to use PDO as the abstraction layer as it makes use of prepared statements and database specific extensions.

He bases it all on PDO object - created and pushed in via dependency injection. The model then uses that object and executes a "save()" containing the data created in the model request. He also talks about "dumb loads", a feature that lets the modeler think it was loaded without having to know anything more than just the object's ID number.

In this new post to his blog Gonzalo Ayuso looks at building an ORM (don't worry, he recommends something like Doctrine first) as an exercise to understand how they're constructed and how one could fit his goals.

What's the motivation for me to build this ORM? The answer is a bit ambiguous. I like SQL. It allows us to speak with the database in a very easy way. [...] So the idea I figured out was to create a set of classes based on my tables, in a similar way than traditional ORMs to help me to autocomplete the fields and table names.

He creates a simple example with a "test" table with three columns with a mapped class (in the "Orm" namespace) that will allow IDEs to follow down the path to fetch the data from the "id", "field1" and "field3" columns. The complete code listing for his example is at the end of the post - PHP 5.3 friendly, of course. Some trigger and scaffolding examples are also included.

On the Zend Developer Zone today there's the first part of a series from Vic Cherubini about an ORM tool he's created to make pulling data from your database of choice (via PDO objects) simpler - DataModler. This first part looks at creating testable models.

DataModeler allows you to create easily testable Models that are not dependent on any datasource. The majority of your logic should take place in the Model, and not the Controller (making your application even easier to test as data sources can be mocked). I try to keep my code as simple as possible, so DataModeler is fairly small.

He talks about how the DataModler tool uses dependency injection and how one primary namespace (DataModlerModel) contains the bulk of the code. He includes code samples showing how to create a simple mode, give the attributes data types and access them via magic "set" and "get" methods. For more information on this ORM tool, check out the latest source on github.