ObjectSpaces questioned: Should object persistence really be thought of as orthogonal functionality?

I know, by asking the question in the subject line, some will view me as a haeretic or as naive or something else. But still, I cannot shed the feeling, that striving for this orthogonality - as Microsoft ObjectSpaces (OS) does - could be harmful. (For my exculpation let me say: since the early 90s I have been a fan of ODBMS and I very much like the thought of transparent object persistence. So I´m all in for a good O/R technology.)
Why do I think so? Because I saw what happened to MTS and then COM+. Many developers did not understand, that designing classes to be run in an application server is different from designing class to be run in a rich client (aka winforms client). Microsoft made it too easy (!) to deploy almost any COM object in an app server application. People could do anything they liked, e.g. keep state, have properties in their app server classes. And that made them unhappy in the end, because performance often was low. But not due to a immature technology, but due to misuse.
So I hope you can agree, that deployment in an app server is not completely orthogonal to the design of my classes. I need to forethink what I´m gonna do with my classes.
The same is true, I now come to think more and more, for persistence. Let me say, at least in many cases. (Maybe sometimes orthogonality is really ok and even desirable. Applications for scientific labs come to my mind, which are more algorithm oriented that database oriented.)
The cases, where I think, orthogonality is not desirable are the typical business applications, the ERP systems etc. Developers know exactly which classes will be filled from a database. They know their persistent objects from the start of the design on. And which objects need to be persisted does not likely change over the lifetime of an application.
So, why should it be suggested to them: forget your knowledge? As long as they still need to explicitly persist changes and even register new objects with OS for change tracking, transparent persistence is not reached in imperative code. Why then should transparent persistence in deklarative code (type definitions) be so important?
Because there already exist classes, whose objects all of a sudden need to be stored using OS? I doubt it. The amount of work to be done in code is still huge.
Because it is so much easier to not think about persistence when designing a class and leave it to some other guy to come up with a mapping? I doubt it. It puts much burden on the persistence engine. And it keeps the gulf between OO world and relation world wide open, because it suggests: don´t talk to each other. You database guy, do whatever you want. And you OO guy, do whatever you want. My experience is, this leads to poor performance in the end, when trying to bridge the gap.
Or because class design should not be tied to a certain persistence technology, be it OS or some other tool? Well, I guess, that´s the real driving force behind the orthogonality idea.
But my feeling is, keeping class design absolutely clean and just spread mapping info across several resources, is the wrong solution.
My suggestion would be instead: Give developers a "domain specific language" (DSL) for the definition of persistent classes. No, don´t try to do it in C#/VB.NET with attributes! Because then you would not be free to maybe sometimes derive from a PersistentObject base class. Instead persistent class should be defined in a special language hiding all implementation details from the developer.
Like HTML is used as a special language compiled to IL in ASP.NET. HTML is a DSL for the realm of presentation layer programming. And we´re all pretty happy with that. So why not have a special language for data persistence programming?
I also suggest, this DSL should not be a fully fledged programming language. No imperative code should be able to be written with it. Whatever business logic needs to be added to persistent classes (to make them less anemic ;-), can be added by derivation or aggregation later on.
My conclusion: A DSL would not interfere with how objects are persisted in code. A DSL still would keep the definition of persistent types clean of any persistence tool specifica. A DSL would make it clear to a developer, he´s dealing with a persistent class. A DSL would help close the gap between OO world and relational world.
From my experience what went wrong with the MTS/COM+ message, I´d love to see it done better for solutions to the object persistence problem.


  • If you have ever done any home repair, you will know that even the best hammer can bruise your finger. (I definitely have scars to prove that) Before you go off too harshly on the object persistence technologies, consider what they are trying to do and how they are doing it.

    When looking at object persistence technologies, generally speaking you will see three different models: A Gateway model, An object extended relational database model, and an object database model. Each of these models has their pro's and con's associated with them.

    ObjectSpaces has some good things going for it (depending on your point of view). For example, ObjectSpaces is a gateway model. One interesting aspect of this model is it can easily be used to access legacy data, something that should not be overlooked when dealing with enterprises. Another aspect is that it is non-prescriptive. This means that you do not have to have persisted classes which derive from some persistable base class.

    (of course I could be jaded)

  • You see, and that´s what I´m arguing against: My point of view is, that persistence should be prescriptive for several reasons. Unfortunately you´re not commenting any of my arguments.

    And don´t get me wrong: OS has some good features. And I don´t want to be too harsh with it or other persistence technologies. But trying hard is no guarantee for doing the right thing or starting with the right premisses. And that´s what I wanted to bring up: The premise is wrong if you think, persistence needs to be transparent or orthogonal. (At least in most cases.)

  • One of the primary goals of OS is not to be prescriptive. It is to allow applciations to create their own prescriptive behaviors on top of it. At the 2003 PDC ObjectSpaces presentation, there was a demo where there was no database or mapping files, just a class definition. A framework on-top of OS was shown which created all of the supporting stuff that was needed. At the same PDC, demostrations of WinFS (another prescriptive model) was shown.

    Which prescriptive model to use should be up to the application implementor. From my experience, some jobs call for simplicity (where a prescriptive model would be intrusive) while others require very clearly defined behavior. The technology should not prevent you from chosing what is best for your situation.

    As far as if object persistence is orthogonal to functionality, it would take far too much to describe my opinion on this matter than I am willing to give using a simple blog text input field. You would have to consider things like what the definition of your object graph is in comparision to your persisted graph, what is object fidelity, etc.... which all impact how someone creates and uses object persistence technology.

  • I think it is a loft goal, not to be prescriptive when it comes to object persistence. A lofty and maybe theory driven goal?

    Microsoft had the same goal when designing MTS. They did not want to be prescriptive with regard to how you design you COM objects. They said: hey, you can host (almost) any COM object in MTS and make it a remote object.

    Well, this worked technologywise - but it was nothing less than a desaster for the adoption rate of MTS. Because people ran into (selfmade) performance problems by the number.

    My point of view: For an object to run remotely or to be persistent has such an impact on how I want to work with it, I should be forced to think of that when I design its class.

    That´s why I think, orthogonality is bad in the case of object persistence in general and OS as a specific technology.

  • Yep. Good post. You are dead-on about having to design a component for life in an application server.

    Per your DSL idea, that's less lofty of an idea now with the CLR. Let me know how it goes ;)

Comments have been disabled for this content.