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.

Comments

• Anonymous
  December 28, 2004
  IMHO, the problems are above the O/R domain. More specifically, trying to do everything you need in an app with a given O/R framework is easier in some scenarios and harder in others.
  
  My thoughts here: http://udidahan.weblogs.us/archives/022647.html
• Anonymous
  December 28, 2004
  The comment has been removed
• Anonymous
  December 28, 2004
  I agree that keeping the actual O/R framework as isolated as possible from the actual code would be a good thing, we're using a commercial .NET mapper at the moment that requires all classes to be derived from a specific type.
  
  Fortunately, the mapper also includes support for multi-table schemas, and the chief advantage (from my point of view) is that we can leverage the existing data (from a creaky system) and re-create (to some degree) an object representation of this.
  
  The mapper we're using is proving to be quite flexible, but the code does become quite invasive. However, this sparked another debate with a collegue and myself (he found another blog post somewhere mentioning this) that to some extent it's not possible to completely isolate the persistence from it's usage.
  
  There are times when it's necessary to control the way items are retrieved on a contextual basis -- lazy vs. greedy loading for instance, or even transactional consistency -- where the only part of the application that can possibly provide any decision is the part that shouldn't be involved.
  
  For example, when building a web app there may be lists of items retrieved (say products) that can be pulled without worrying about locking. However, when updating an item between page postbacks or requests, it may be necessary to ensure the object is locked until the changes are committed or discarded. Despite desires to keep the persistence framework isolated from the business layer, and application layer, it's not possible to (or at least not sensible to).
  
  It's something I've been thinking quietly for a while, and I'm sure there's a neat solution out there using IoC, I just haven't had enough time to draw anything :)
  
  At present, I find the extent to which our framework determines our code structure a nuisance but not a killer. The benefits afforded by having greater control over the system are extremely beneficial.