Unlike mappers, though, which are part of the infrastructure, a repository characterizes itself as speaking the model's language, as it's intimately bound to it. And because of its implicit dependency on the mappers, it preserves the persistence ignorance as well, therefore providing a higher level of data abstraction, much closer to the domain objects.

Included in the tutorial is the full code you'll need to create a simple UserInterface class and a User model that extends it. He also makes a UserCollection class to handle working with multiple User objects and a UserMapper to handle the actual data source fetching. Finally, he implements the Repository on top of this base structure showing how it lays on top of everything via the UserMapperInterface instance. At the end some example code showing it in use is also included - making the PDO connection, creating the UserRepository and fetching by a few different data types (email, name and role).

The phrase may sound like an cheap cliché, I know, but I'm not particularly interested in reinventing the wheel each time I tackle a software problem (unless I need a nicer and faster wheel, of course). In this case, the situation does warrant some additional effort considering we'll be trying to connect a batch of mapping classes to a blog's domain model. Given the magnitude of the endeavor, the idea is to set up from scratch a basic Data Access Layer (DAL) so that domain objects can easily be persisted in a MySQL database, and in turn, retrieved on request through some generic finders.

He includes all the code you'll need to create a (namespaced) database adapter (PDO), the mapping layer to tie the domain models together and using it all in a practical "blog" example with posts, comments and users.

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.

Part of our business is to develop internal applications and support customers, so we dedicate a good amount of time to research, test and learn new technologies. We have been following this whole movement and decided to give MongoDB a try. What has really taken our attention regarding MongoDB is its simplicity, yet how powerful it is. It lowers the barrier to develop DB-driven applications even more.

They start by explaining how to use MongoDB together with PHP and get both the server and client sides up and running. From there they introduce ODM, a object document mapper from Jon Wage (of the Doctrine project) that lets you easily interact with MongoDB instances. A code sample it provided to show how simple the tool is to use and how it can integrate with symfony as an entity.

I was struggling getting my data models (as described in the Zend Framework Quickstart) to work with relations. My first solution was to create a database view that merged that data using joins to collect this data in a format that I could use in my data models. This was going great until I looked at my database where it contained over 20 views (along with 20 data models, mappers and db table gateways) ! So I said to myself there had to be another way.

His other way came in the form of the Zend_Db_Table_Relationships component and, after a bit of work, it did just what he needed. He shares how you can set them up similarly by walking you through the creation of a sample application ("datamodels") and linking together a series of sample tables with a Db_Table class using relationships, a simple model to abstract data access and a model mapper class to redefine some of the based functions (like "findAll") to pull in data from other tables.

Today I am happy to tell you that we have two new versions of Doctrine available for you to use. The first is the monthly maintenance release for Doctrine 1.0 and the second is another release candidate for the newest major version of Doctrine, 1.1. As always you can grab them from the downloads page.

Updates in these two versions include a few backported fixes from 1.1, updates to the Doctrine_Query::count() method for optimization, and several fixes in the Release Candidate in preparation for the next release. You can see the full Changelogs here: 1.0.8 and 1.1.0-RC2.

Tim set a simple, but very much real-world challenge; write an app that determines the top 10 most popular blogs from his Apache access log. It should be fast and readable, with a subtext of illustrating how "language X" copes in terms of parallel processing and utilizing "wider" (many processor) systems.

Since PHP natively doesn't support multi-threading (well), Harry opted to go with an approach using curl_multi_exec instead. There's two pieces to the puzzle - the mapper to grab the information and extract the data and the reducer that makes the calls to grab the information from the log files.