Archives

Archives / 2004 / February

  • Thoughts on how to bind to databases, or: Databases as services

    2 Comments

    There´s much talk about O/R mapping tools lately in the .NET world. ObjectSpaces are slowly materializing and more and more 3rd party vendors are offering their solutions. But when looking at the different solutions I´m still feeling kind of uneasy. But today I have been able to lay my finger at least on part of the reasons for my uneasyness: I´m not yet satisfied with the way we bind our programs to databases.

    Read more...

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

    5 Comments

    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.

    Read more...