Orthogonal to Orthogonal

I think Ralf post about “Should object persistence really be thought of as orthogonal functionality?” is orthogonal to the real problem that ObjectSpaces is trying to solve.  It seems his overall point is that by allowing any domain objects to be persisted to a relational store will lead to some cases where the developer designs domain models which have poor performance for persisting to the store.  In other words, he is hitting on the age old adage of to much abstraction and balck box magic can give the developer enough rope to hang themselves.  Sure, I won’t argue that point, but I believe that is orthogonal to whether ObjectSpaces should be a prescriptive framework or not.


ObjectSpaces is designed to work with POCO (plain old CLR objects) since it gives the developer of the domain model the most freedom.  This is designed to be a productivity gain and hopefully will supplant a large amount of the home-grown O/R mapping libraries that exist today.  From that stand point, I am not sure I really understand how ObjectSpaces would introduce performance problems that don’t already exist in an applications design.  IMO, the potential for performance problems comes from the flexibility in the mapping. 


To persist an POCO object, ObjectSpaces roughly needs four things:  the current objects, the object state, the original values (including hidden values), and the types mapping information. Currently this information is contained in the ObjectManager, but it very well could be distributed to each domain object via an base class or a transparent proxy.  To me, that is almost a question of style – and each model has advantages/ disadvantages.  In fact, I think the ultimate O/R framework would support all three models which would allow for the greatest flexibility.  However, I believe that is orthogonal to whether the developer can use the framework to develop a poor performing design.


Think of an absurd case where the developer has hundred of types in my system each with a single property each mapping to a unique table my database.  This is not going to perform under any scenario since the queries being generated for any interesting scenario are going to be quite complex.  Whether or not the developer is using an O/R framework isn’t going to make any difference – independent of whether it is prescriptive or not.


However, I don’t want to be completely naive here.  Developers using ObjectSpaces will have to understand that their types are being persisted to a datastore.  This means making design decisions in their application roughly analogous to the type of design decisions distributed applications have to make, dealing with optimistic concurrency issues, thinking about transaction boundaries, etc … all the same decisions the typical ADO.net developer has to think about today.  I’m not saying it will be exactly the same and it will take some time to figure out what the new programming idioms are when working with ObjectSpaces, but it’s going to be quite similar.

Comments (2)

  1. Dan Golick says:

    I guess my real concern with ObjectSpaces is the handling of versioning of the objects.

    The XMLSerialization of classes in .net does not easily handle versioning of classes. This is in contrast to MFC serialization where code could steer the sterialization based on the version number of the stored class.

  2. Peter says:

    You keep saying that Objectspaces works with POCOs and that’s not true.

    It would have been true if you did not support delayed loading and made it explicit. This will also avoid the issues discusses by mwarren.