O/R redux

One of the big conversations that has been going on for some time in the Java world is how prescriptive container frameworks such as EJB and Spring should be. It is fairly well known, that for O/R mapping frameworks the same conversation exists since O/R persistence is really just one (albeit complicated) service that can be provided by a container. The Java folks like to refer to POJO versus non-POJO solutions. Inside Microsoft, when discussing O/R – we talk about POCO (Plain old CLR objects) and prescriptive versus non-prescriptive. Ignoring the details of implementing the various frameworks (IoC etc), it’s really all the same discussion.

The POCO/ POJO concept is fairly straight forward. The proponents suggest that a good O/R solution should allow the user to map simple domain model classes to the persistent storage without requiring the class to implement interfaces or inherit from specific base classes. In other words, there are no prescriptive requirements for the domain model developer and the types being developed could be used outside of the context of the O/R framework. They are free to develop their domain model as they like and is decoupled from the database schema. I like to call this “design time” transparency.

Nanshan Zeng – a coworker of mine for several years now in both the Xml and ObjectSpaces teams made some interesting points about this topic when we were talking a couple of weeks back. He said that in terms of O/R, the POJO/ POCO is really somewhat of a red herring and that the real conversation should be about the flexibility and extensibility of the mapping solution. In other words, if one is mapping to an existing legacy data store how much of the abstract is leaky and therefore causes the database schema to dictate the domain model type hierarchy.

For example, if my O/R framework only supported mapping a given type to single database table/ view then I would be limited to developing domain model types which were 1-1 with the database tables. Obviously, there are ways to fix this – creating a database view or mapping to a sql query instead of a table, but I think the example illustrates my point.

It seems that although there are some interesting opinions on the amount of flexibility required to make a good O/R framework, there seems to be some good solid agreement that POJO/ POCO solutions must provide non-prescriptive and flexible mapping solutions. And although the anti-EJB crowd would most likely disagree, I am beginning to think that the latter is much more important.