How much object relational framework do you really need?


It is always interesting for me to look at debates about object relational layers. I propose we define different levels of object relational support:



  1. No support: all the objects are persisted and queried by writing ADO.NET code by hand

  2. Code generation: you run a tool on your database (or on an abstract description of your schema) and the tool generates a bunch of objects for your tables and some ADO.NET code to retrieve/persist their state


    1. Total code gen: the tool generates all the ADO.NET code

    2. Partial code gen: the tool generates just code to intercept property accessors and provide delay loading, but all the data access code is in a separate compiled component

  3. Metadata based: no code generation phase. The access to fields and property goes through reflection and the data access code is not exposed in the user code


    1. Semi transparent: the persistent classes or properties need to be marked in some special way to be persisted (attributes, inherit from a special class or such…)

    2. Transparent: the classes don’t need to be modified at all to be persisted

Things get fuzzy, though. It is sometime unclear the difference between 2.2 and 3.1 and various creative solutions can be hard to classify. But in a general sense, this classification is probably about right. In a generic sense EJB1.1-2.0 is a 2.2, EJB3.0 is a 3.1, JDO is 3.2 (if you don’t consider post-compilation) and ObjectSpaces is a 3.2. Hibernate and Toplink are squarely 3.2.


But do you really need to go all the way to 3.2? All the times? I’ll try to post more about trade-offs in all these solutions, but if you have an idea of a better categorization, please let me know. The one I propose is right out of my head and I’m not to happy about it either.

Comments (2)

  1. Aaron says:

    In my group, we go the opposite direction, and I find it quite nice.

    We codegen stongly-typed methods which correspond to the stored procs. This inspires a rather chunky SOA-style design all the way down to the persistence layer. Which is Good Thing, since databases are slow after all.

    I guess it’s not as "cool" as obj relational frameworks, but it works, it’s fast, and it’s pretty simple.

  2. Paul Wilson says:

    My ORMapper (http://www.ORMapper.net), along with what was once MS ObjectSpaces, can be pure 3.2, but also allows for an optional interface to be implemented to avoid reflection (I’m not sure if that corresponds to your 2.2 or 3.1 though).