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
  3. Total code gen: the tool generates all the ADO.NET code

  4. 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

  5. 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

  6. 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)
  7. 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.