Skip to content - the long road to a php data mapper - part 1

I am working on the private project "" to get away from social services and have a tool that fits perfectly to my own requirement. Private projects always (should ;-)) have the benefit of "no time preasure" that leads to "implement some cool features". The first thing on this feature list is a data mapper.

Why a datamapper? Well, won't you like to work with domain models and don't give a s*** about how and where the data is stored? There is a wonderfull and short article created by Martin Fowler and i just have to recomend this one.

I found two datamapper projects for php on the web, pdodatamapper and phpdatamapper. To keep things short, a data mapper removes the logic of "how and where" to store the model data. Both projects are still under heavy development and are not in a final state right now. I will not use them (but always take a look on how they have things done).

So what should my data mapper do? All in all, it should hide all the database tables from the developer - even the orm if used. I just want to create a domain model and use it to store and get data from a persistent storage. My data mapper must be smart enough to figure out which rowset on which storage/database table he has to update (or create). The data mapper should have a lazy loading/storing mechanism, this should be done by a propertieset that knows which propertie is stored on which storage/database table. My data mapper should support a very simple/limited filter mechanism that prevents me to blow up my data mapper class with to many "loadModelWhenItFitsToTheFollowingCircumstances"-methods. This data mapper should also support to create a domain model by the upper called filter mechanism.

I decided that the general data mapper methods "insert()", "update" and "delete" are not perfect in the matter of sense to fit on my requirements. Thats why this data mapper will have the methods "load($model, $filters)", "save($model)" and "delete($model)". You can adapt each data mapper by adding own load methods with pre defined filters.

Filter what? All this filtering leads to a filter class. This is a simple and straight forward one with the properties "criteria", "name" and "value". The filter class has to be independent from the real storage implementation, thats why i will use an aditional filterMapper class.

This filterMapper is used from the data mapper and prevents to write doublicated storage dependent code. He is responsible to transform the general filterset to the a storage dependant model - means you throw the filter and the storage model inside and get the storage model with added storageFilter back. That filter and filterMapper can communicate with each other by using a criteria class. The criteria class will define what "like" or "greater then" is so that the filterMapper can map this to the storage model.

After the trip to the filtering adventure, we are back to the data mapper itself. The real domainModelDataMapper will use a general propertieSet class. This propertieSet class is the only real connection between the domainModelProperties and the (maybe more the one) storage models - so the theorie currently ;-).

I must admit, i have made no decision if the real domainModelDataMapper is a decorator of the dataMapper, or if the dataMapper class is implemented as abstract class. Since the whole project is a "learning by doing", i will figure out what will work - final in the phase of implementation (have i remarked that i never ever have worked with a data mapper for real? ;-) ).

Lets see what is next.

Translate to de es fr it pt ja