DAO as Data Mapper – Distinguishing Objects from tables

There is no question that in simple applications, there may be a pretty good correlation between objects and tables, but once you get beyond trivial applications, you find a bunch of cases where your object model and your data model diverge as one is designed to optimize the comprehensibility and maintainability of your code and the other is designed (within reason) to optimize the performance of the persistence mechanism for the attributes of the objects that should be persisted.

I’d been thinking about this a lot. I distinguished attributes from properties and looked at issues like ordering by attributes. An interesting pattern I came across while perusing through Fowlers P of EAA was the Data Mapper which describes a pattern I have been working on within my DAO that allows you to have truly object based DAOs that use ORM patterns to handle the object-relational impedance mismatch.

To me, the goal of a DAO is to handle persistence, but ONLY the DAO should know about persistence specific issues. I don’t think the application should know that you persist date of birth rather than age. It should just be able to ask for a User object with an Age and the DAO should be smart enough to figure out that for Age to be displayed, date of birth needs to be retrieved and loaded into the IBO. That is what the data mapper pattern is for, handling such translations so that the object model and the database can be less tightly coupled.

There is an argument for putting the data mapper between the business object (or service layer) and the DAO. The benefit is that it would make the DAO simpler so if you needed to support multiple persistence mechanisms, all of the mapping logic would be broken out in a separate class that would then use an abstract factory approach to get the right DAO (actually the right DAO would be injected into the mapper using a programmatic config file in LightWire or multiple config files for ColdSpring). I haven’t decided whether to do this as the data mapper pattern isn’t very well known in the CF world and I don’t want to confuse people, so I’ll start with discrete methods within the DAO and then introduce a mapper if it seems appropriate when I’m working with the code.