O/R redux

One of the big conversations that has been going on for some time in the Java world is how prescriptive container frameworks such as EJB and Spring should be.  It is fairly well known, that for O/R mapping frameworks the same conversation exists since O/R persistence is really just one (albeit complicated) service that can be provided by a container.  The Java folks like to refer to POJO versus non-POJO solutions.  Inside Microsoft, when discussing O/R – we talk about POCO (Plain old CLR objects) and prescriptive versus non-prescriptive.  Ignoring the details of implementing the various frameworks (IoC etc), it’s really all the same discussion.


The POCO/ POJO concept is fairly straight forward.  The proponents suggest that a good O/R solution should allow the user to map simple domain model classes to the persistent storage without requiring the class to implement interfaces or inherit from specific base classes.  In other words, there are no prescriptive requirements for the domain model developer and the types being developed could be used outside of the context of the O/R framework.  They are free to develop their domain model as they like and is decoupled from the database schema.  I like to call this “design time” transparency.


Nanshan Zeng – a coworker of mine for several years now in both the Xml and ObjectSpaces teams made some interesting points about this topic when we were talking a couple of weeks back.  He said that in terms of O/R, the POJO/ POCO is really somewhat of a red herring and that the real conversation should be about the flexibility and extensibility of the mapping solution.  In other words, if one is mapping to an existing legacy data store how much of the abstract is leaky and therefore causes the database schema to dictate the domain model type hierarchy. 


For example, if my O/R framework only supported mapping a given type to single database table/ view then I would be limited to developing domain model types which were 1-1 with the database tables.  Obviously, there are ways to fix this – creating a database view or mapping to a sql query instead of a table, but I think the example illustrates my point.


It seems that although there are some interesting opinions on the amount of flexibility required to make a good O/R framework, there seems to be some good solid agreement that POJO/ POCO solutions must provide non-prescriptive and flexible mapping solutions.  And although the anti-EJB crowd would most likely disagree, I am beginning to think that the latter is much more important.

Comments (3)

  1. IMHO, the problems are above the O/R domain. More specifically, trying to do everything you need in an app with a given O/R framework is easier in some scenarios and harder in others.

    My thoughts here: http://udidahan.weblogs.us/archives/022647.html

  2. Frans Bouma says:

    I think the real question is: why is it bad that your classes aren’t as abstract as they theoretically could have been? To provide real POCO persistence, you have to sacrifice a lot. Especially in distributed environments where you can construct an object graph on the client and send it over to the server to get persisted is hard to do in a plain POCO solution, as it has to crawl through all the objects and inspect every property.

    In the .NET O/R mapper world, we more or less agreed that plain POCO is ‘nice’ but not efficient enough.

    I also want to add that the whole debate about domain model comes first etc. is very academic. Developers want to use what works, not what some clean-room developers think is great. Especially in large scale applications, for example large ASP.NET websites on a large oracle database with hundreds of tables, you don’t want to write hundreds of classes and thousands of lines of code by hand just because ‘the domain model is better’, you want to use what works and what gives you that gain in time, say 30-40%. In these projects, debates about ‘POCO’ and ‘Domain model’ are rather unlikely, at least that’s my experience. Deadlines are often planned early, projects are short, the amount of work to do is huge and 9 out of 10 times the database is already there and filled with millions of rows.

    Sure in projects with 10 or 20 tables, where you start from scratch, POCO is perhaps ‘a’ way to do it, but even then you can argue that it’s the world upside down: Yourdon and Chen weren’t stupid, the entity-relational model isn’t bad and it is very well suitable to work with in an OO model, you don’t need a large scale translation framework in place to translate your POCO graphs to tables and back.

    Also, if you use proven techniques who are already available for over 20 years, you develop a solid entity relational model, (for example using ORM, a technique developed by a collegue of yours, prof. T.A. Halpin :)) and use that as a base for your data-foundation. Techniques on the market today can use that model to build the data foundation for you, without a single line of code to write, but with O/R mapping techniques build in.

    Not only do you then have a solid foundation (which is based on theory: the datamodel is theoretical correct), you also have a better chance of keeping close to your functional research document, as the ORM model is part of that document. Staying close to research documents has the advantage that you can track back functionality implementations easier by starting at their theoretical starting point (the functional research), you can also do the opposite, which is KEY for a maintainable software system.

    The last 6, 7 months showed some interesting things in the .NET world. Pure O/R mapping is on its way back, it’s staying a niche. Tools/frameworks which utilize O/R mapping techniques in a more practical way however are getting more and more attention and are more and more successful.

    "It seems that although there are some interesting opinions on the amount of flexibility required to make a good O/R framework, there seems to be some good solid agreement that POJO/ POCO solutions must provide non-prescriptive and flexible mapping solutions. "

    This is precisely why pure O/R mapping will not succeed in .NET. The average .NET developer doesn’t get this poco mapping stuff, he wants to work with data, he works with a database, that’s what he’s learned in the last decade working with MS development frameworks. On Java that was never the case, but on .NET the vast majority of people are products of Windows DNA/ADO training.

    Furthermore, your remark might sound great in a management report, it’s almost impossible to create a very flexible POCO mapper solution that also performs great. Sure, you can map whatever property on whatever table field using whatever datastorage mechanism to store the mapping. The problem isn’t producing that mapping, the problem is to check which property has changed, which entity to save etc. and that in a distributed environment. Again, in a 2-tier 20 table application, no big deal. But in a 3-tier, distributed application with a large database it IS a big deal, where a 10-person team works solely on the gui and is not allowed to call any persistence methods but has to consult a remoted service.

  3. P. Ingles says:

    I agree that keeping the actual O/R framework as isolated as possible from the actual code would be a good thing, we’re using a commercial .NET mapper at the moment that requires all classes to be derived from a specific type.

    Fortunately, the mapper also includes support for multi-table schemas, and the chief advantage (from my point of view) is that we can leverage the existing data (from a creaky system) and re-create (to some degree) an object representation of this.

    The mapper we’re using is proving to be quite flexible, but the code does become quite invasive. However, this sparked another debate with a collegue and myself (he found another blog post somewhere mentioning this) that to some extent it’s not possible to completely isolate the persistence from it’s usage.

    There are times when it’s necessary to control the way items are retrieved on a contextual basis — lazy vs. greedy loading for instance, or even transactional consistency — where the only part of the application that can possibly provide any decision is the part that shouldn’t be involved.

    For example, when building a web app there may be lists of items retrieved (say products) that can be pulled without worrying about locking. However, when updating an item between page postbacks or requests, it may be necessary to ensure the object is locked until the changes are committed or discarded. Despite desires to keep the persistence framework isolated from the business layer, and application layer, it’s not possible to (or at least not sensible to).

    It’s something I’ve been thinking quietly for a while, and I’m sure there’s a neat solution out there using IoC, I just haven’t had enough time to draw anything 🙂

    At present, I find the extent to which our framework determines our code structure a nuisance but not a killer. The benefits afforded by having greater control over the system are extremely beneficial.