commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Field-Elliot <>
Subject Re: Jakarta Persistence Framework?
Date Mon, 17 Dec 2001 19:08:13 GMT
First, let me clarify, I'm not interested in re-inventing the connection

What I _am_ interested in, is a simple framework which maps JDBC tables
to Java classes, with getters and setters, which roughly meets these

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


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.
    Jason van Zyl
    To unsubscribe, e-mail:   <>
    For additional commands, e-mail: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message