commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Jakarta Persistence Framework?
Date Mon, 17 Dec 2001 19:13:09 GMT
On 12/17/01 2:08 PM, "Bryan Field-Elliot" <> wrote:

> First, let me clarify, I'm not interested in re-inventing the connection
> pool.
> What I _am_ interested in, is a simple framework which maps JDBC tables
> to Java classes, with getters and setters, which roughly meets these
> goals:

This is what Torque currently does but will be expanded as the table->object
mapping rarely is enough for an application unless you are starting from
scratch and have full control over the project. Many times your application
object may consist of fields that are potentially pulled from multiple

But Torque definitely does the table->object mapping now and has for a long
while and is very stable.
> - Ability to easy create a new class which models a table (or, if not a
> POJO (Plain Old Java Object), then the new DynaBean)
> - Easily model the concepts of a "finder" (execute a query, return many
> entity objects)
> - Easily handle creations/deletions/updates, with the framework
> communicating your changes to the database
> - Easily wrap up transactions from within Struts' way of doing things
> (begin tran before executing an Action, and commit tran at it's
> conclusion; rollback if an exception is thrown; allow the Action to
> explicitly rollback).
> - Easily allow Struts Actions to hand these entities (or collections of
> them) to the View for rendering into HTML etc -- in a way that makes
> these entities read-only and detached
> - Easily handle some of the more ugly, common tasks in JDBC development
> - namely, (1) primary key generation, and (2) optimistic concurrency
> locking
> - Keep It Simple - this should NOT balloon into a huge framework - it's
> source should always be readable and understandable by most - if you
> need something more complex, go get JBoss or one of the bigger
> frameworks recently mentioned here.
> Other "sliding scale" factors include:
> - How easy do you want to make it for developers to build their entity
> classes? The easier you make it, the more complex the underlying
> framework is likely to become. Do you do automatic class generation
> (from an XML file), or can you declare everything within your own
> classes (which perhaps extend a framework base class)?
> - Is there automatic "change detection" (ala EJB), or must the developer
> execute some kind of "update()" method after changing a bean? Automatic
> change detection would give the developer one less thing to
> remember/worry about, however, it can really balloon the framework.
> Personally I lean towards leaving out change detection and letting the
> user (me) remember to call update() before my bean goes out of scope.
> Everyone (and every framework) strikes its own balance, roughly, between
> ease of use vs. framework simplicity. I've found a balance point which
> feels right to me but may not for others. I'd be happy to put something
> up here in the next few days to show where it lies, if there's interest.
> If, instead, I get cries of "stop reinventing the wheel" then perhaps it
> had better be put to rest. But in any case I do see value in providing
> the option of a Struts-friendly, far-lighter-than-EJB (but more meaty
> than simple JDBC wrapping) framework.
> Bryan
> On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote:
>   On 12/17/01 1:35 PM, "Bryan Field-Elliot" <> wrote:
>> Well, I certainly don't like to see work duplicated, and it seems that
>> there are many other efforts under way (some of them within Jakarta) to
>> build a generic persistence framework. That said, however, some
>> additional considerations might still point towards the usefulness of a
>> new framework:
>   That's certainly true, there are a couple webapp frameworks here, three
>   connection pools, two service frameworks and now one in the sandbox so if
>   you need a persistence layer and you feel none of them satisfy your needs
>   than you won't be starting any new trends. If you find it easier working in
>   a smaller group with people that have similar needs (which I find working
>   within the turbine world, and you may find the same working with struts
>   developers) than that's what you have to do. No one here has really tried
>   that hard to unify everything, and in reality that's probably not ever going
>   to happen and diversity is a great thing
>   If you have ideas, than put them in the sandbox and let people look at them.
>   -- 
>   jvz.
>   Jason van Zyl
>   --
>   To unsubscribe, e-mail:
> <>
>   For additional commands, e-mail:
> <>



Jason van Zyl

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message