| |
6:46:02 PM |
 |
Jakarta Commons. Its very early days, but there's a new component being developed in the Jakarta Commons Sandbox called commons sql which is hopefully gonna be a little tool that given a relational schema model, specified in XML like this can then be parsed into beans and used to auto-generate SQL DDL for different databases, generate HTML documentation, Java beans and OJB repository files etc. Then tools like Velocity or Jelly can be used to do the code generation. [james strachan's musings]
The problem with the data-centric approach of Commons-Sql (and OfBiz, and Torque, ADO.NET, etc) is they approach persitence from the wrong way round. Data-models are still thought of data-models - they just have a nicer interface than raw SQL (be it Java objects, generic value objects or XML).
Using code-generation or value-objects means the data has to reside elsewhere. This often (but not always) leads to a Transaction Script approach where there are coarser grained methods performing functionality on data.
But OO gives you much more, namely the ability to associate state and behavior by encapsulating them in a single object. This object-centric approach leads to cleaner, simpler and generally more scalable designs by encouraging a Domain Model [comparison]. To leverage this in a persitence layer, it needs to work the other way round - the objects are created first (with state and behavior) and the persistence layer magically engineers the database from this.
Many people believe that the data is the application - I generally don't (please, I'm not saying it's wrong, it's just my preferred approach and there are 10 zillion reasons where this approach is better). To me the behavior is the app - 'given this, does that happen?'. Along the way, certain elements of your objects need to be persisted, so you engineer your persitence from the object model. The subtlety here is that the state of objects is encapsulated within them instead of elsewhere. Deriving your persistence leads to cleaner and simpler applications.
As clunky as entity beans are, they do encourage the Domain Model approach. Of course there are more elegant solutions, Kodo (a commercial but affordable JDO implementation) being my personal favorite.
| 