It is al­ways in­ter­est­ing for me to look at de­bates about ob­ject re­la­tional lay­ers. I pro­pose we de­fine dif­fer­ent lev­els of ob­ject re­la­tional sup­port:

1. No sup­port: all the ob­jects are per­sisted and queried by writ­ing ADO.NET code by hand

2. Code gen­er­a­tion: you run a tool on your data­base (or on an ab­stract de­scrip­tion of your schema) and the tool gen­er­ates a bunch of ob­jects for your ta­bles and some ADO.NET code to re­trieve/​per­sist their state

3. Total code gen: the tool gen­er­ates all the ADO.NET code

4. Partial code gen: the tool gen­er­ates just code to in­ter­cept prop­erty ac­ces­sors and pro­vide de­lay load­ing, but all the data ac­cess code is in a sep­a­rate com­piled com­po­nent

5. Metadata based: no code gen­er­a­tion phase. The ac­cess to fields and prop­erty goes through re­flec­tion and the data ac­cess code is not ex­posed in the user code

6. Semi trans­par­ent: the per­sis­tent classes or prop­er­ties need to be marked in some spe­cial way to be per­sisted (attributes, in­herit from a spe­cial class or such)

7. Transparent: the classes don’t need to be mod­i­fied at all to be per­sisted

Things get fuzzy, though. It is some­time un­clear the dif­fer­ence be­tween 2.2 and 3.1 and var­i­ous cre­ative so­lu­tions can be hard to clas­sify. But in a gen­eral sense, this clas­si­fi­ca­tion is prob­a­bly 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 con­sider post-com­pi­la­tion) and ObjectSpaces is a 3.2. Hibernate and Toplink are squarely 3.2.

But do you re­ally need to go all the way to 3.2? All the times? I’ll try to post more about trade-offs in all these so­lu­tions, but if you have an idea of a bet­ter cat­e­go­riza­tion, please let me know. The one I pro­pose is right out of my head and I’m not to happy about it ei­ther.