OR Mapping analogy

Mats Helander did a post comparing OR mapping to virtual memory in modern computers. It was a great post, comparing data oriented and object database visions of OR mapping. The key to his idea is that to fully embrace OR mapping in the object oriented database style, you must give up on managing the lifecycle events of your domain objects. You do this just like programmers gave up managing application memory a long time ago when virtual memory gave every application the illusion of having all the memory it needed. The operating system maintains this illusion, swapping parts of the program in out out of memory as needed. Mats' analogy is that on OR mapper when used to it's fullest potential does the same thing for your domain. The application just updates domain objects, and the the mapper takes care of how and most importantly when the changes are flushed to the database.

This is both simple and clear and I started including it as a prerequisite to training on NHibernate. Like all visions though, it is not complete. I had the pleasure of talking with Mats about this in Cortina at our most excellent software workshop there last January. I think I can correctly characterize his response by saying he agreed there is unfinished business here. Here are some of the problems with the vision. These represent both obstacles from the tools and of methodology obstacles that just have to be worked through.

1 - Virtual memory does not attempt to give an application unlimited memory, just a "large enough" pool of memory. Databases on the other hand are assumed to be able to grow as needed to any size. That assumption can never be true in an in memory model. It does turn out to be true in a surprising number of applications though.

2 - Building on point number one, database tools assume that some data sets can only be processed in streams(or sets) but OR mapping tools typically don't give you streams of objects. It would be easy to do, but the mental model is wrong because the application has to get involved in the act of retrieving from the database.

3 - The tools don't do a great job of allowing you to move easily between a "disposable" in memory only model and a persisted model. This comes into play whenever you do a what if scenario: modeling price increases for example or projecting forward from a current state to a future state for purposes of experimentation. Throw in lazy loading you have some real technical challenges.

4 - The programming world has internalized the idea that the lifecycle events, create, delete, update, are where we do important state management tasks. Validation, workflow, logging, observers are all plugged into these lifecycle events. We get them for free so forcing something else to trigger these state management processes is a loss for us. Where do we do this if we don't control the lifecycle events?

5 - I have heard others say, and I find myself agreeing that we should allow invalid objects to be persisted. This is a certainty a possibility if #4 is solved. If we save objects in an invalid state, we have to get really good at the state pattern or some alternative like it. If the state problem is handled in code, we have to make sure that nothing can access the database directly. That means that we have to solve the reporting problem with our domain model.

6 - Mats and others have already written about this, but versioning is another break in the analogy. When an application quits, virtual memory is freed, the contents never to be seen again. Not so with long term database storage. Who's responsibility is it to update old versions to new versions? Databases avoid the issue entirely: there is no old version and it's the dba's responsibility to (manually) handle any data updates required to support schema changes. Solving this would be a big win.

Overall, and the kind of mean spirited post by Clemens Vasters to the contrary, OR mapping has come a long ways in the last 4 years. It has become practical for a much larger class of applications. Rails has probably set the stage for OR mapping to hit the masses and what a change in point of view that would represent. More on that in an upcoming post.