PHP, Data Access Metadata Mapper
In thinking about the post I made a couple of days ago about PHP and the idea of using a Data Access Layer it had inspired me to do some reading. So I have been digging through Martain Fowler’s book Patterns of Enterprise Application Architecture (pictured to the left). Three patterns I have been reading about lately are the Metadata pattern, Query Object pattern and Repository pattern. I am going to discuss the Metadata pattern and save the Repository pattern and Query Object pattern for a another post.
I have worked with Microsoft’s Repository Factory guidance package in the past. It was embedded in their Service Software Factory at the time I had used it. The guidance package was essentially a code generator that allowed a developers to create stored procedures, domain objects, a map between stored procedures results and domain objects, and repository objects that encapsulated all database interaction.
Metadata pattern …
A Metadata Mapping allows developers to define the mappings in a simple tabular form, which can then be processed by generic code to carry out the details of reading, inserting, and updating the data.
How Microsoft implemented it was by creating factory pattern interfaces and classes. They implemented an IDomainObjectFactory interface who purposes was to define a mapper between query results and a domain object (business class). Classes implementing the interface accepted a IDataReader object map the result set columns to a domain object properties and return the populated domain object. That takes care of mapping the results to the domain object. To go the other direction an IDbToBusinessEntityNameMapper is used. It is embedded in this Query Object classes so that a domain object can be passed to the implementation for the query factory and mapped to parameters for the given statement.
The Microsoft implementation used generics to allow the interface to remain flexible while the implementing classes could deal with concrete domain objects passed in as a template. It also made it wonderful for returning List of objects in the cases where a get all selection was required.
To apply this pattern to PHP classes there are a number of challenges. First, by default the PHP implementation of a database query returns a result array that is indexed with numbers and not keys. In looking at this it appears that PEAR’s fetchRow(DB_FETCHMODE_ASSOC) functionality will fix this and allow the mapping of column strings to object properties. Second is in PHP there is not the concept of generics but this may be already solved by the fact that PHP is not strongly typed. A domain objects can be passed as an object reference with no issues. The interface will not have to specify the implementation of the object passed back. The only thing that makes me somewhat uncomfortable is the fact that the implementing class won’t either. I need to think on this more.
The end goal of the research would be to write a PHP code generator program that would allow a developer to connect to a database and create domain objects from the database, build queries, map the results to domain objects, and build repository classes in the same way that Microsoft’s guidance package would.
[...] Object Query pattern from the book Patterns of Enterprise Application Architecture. The previous discussion about the Metadata mapper pattern talked about how to map domain objects to database [...]