commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Winterfeldt <dwinterfe...@yahoo.com>
Subject Re: Jakarta Persistence Framework?
Date Mon, 17 Dec 2001 20:59:39 GMT
I had started on auto-generating classes based on a
database table as a proof of concept, but I haven't
worked on it anymore since I found out it about
Torque, Castor, etc.  I liked the idea of keeping
things very simple and generating jdbc code that you
would have written yourself so it would be easy to
look at and edit.  I thought that one of the
transformation packages could be used to copy to and
from the ActionForm and the PK and Data classes.

http://home.earthlink.net/~dwinterfeldt/generator/

Overview
http://home.earthlink.net/~dwinterfeldt/generator/overview.html

I just thought I'd mention this in case you want to
look at it. 

David

--- Bryan Field-Elliot <bryan_lists@netmeme.org>
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:
> 
> - 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"
> <bryan_lists@netmeme.org> 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
>     
>     http://tambora.zenplex.org
>     http://jakarta.apache.org/turbine
>     http://jakarta.apache.org/velocity
>     http://jakarta.apache.org/alexandria
>     http://jakarta.apache.org/commons
>     
>     
>     
>     --
>     To unsubscribe, e-mail:  
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>     For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>     
>     
>     
> 


__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message