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.
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.
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.
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