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 17:58:53 GMT
I see where you're going with that...

If I understand you correctly, your framework is simpler than mine even
-- a pretty thin layer over JDBC, whereby all table access is via
generic functions to open a table (or maybe a query?) and iterate
through it's raw rows.

My framework is closer to EJB -- you end up implementing a class for
each table of your database, with getters/setters for every field. 

However, in the case where you want to iterate through the results of a
complex query (perhaps a join across multiple tables), a raw query and
iterate over results (like yours) might be more appropriate than an
"entity" based approach like mine (and EJB).

Still I'm hoping to hear from others as to whether there already is
something like this in one of the other Jakarta projects, or maybe even
already in the commons/sandbox.



On Mon, 2001-12-17 at 10:44, wrote:

    I'm very interested in such a thing. I'm in much of a similar position and
    would like to try and submit design ideas into it.
    My biggest problem with Struts was that coders kept passing Form objects
    down to the EJBs, thus tying the EJBs to Struts. So my design there used a
    generic Namespace interface. BeanNamespace, ServletNamespace, MapNamespace
    etc to form nice ways of passing information down to the DAO/EJB/Whatever
    your name is. As a Form is just a Bean, you wrap the Form in a
    BeanNamespace, and pass it to the EJB which takes a Namespace interface.
    It does create a loosely typed system however.
    I've been working on a generic Store API with the plan of making life
    amazingly simple. ie) it sits on top of new database format and allows a
    user to do something like:
    Store store = new Store(connection);
    Table table ="people");
    RowIterator rows = table.iterator();
    while(rows.hasNext()) {
        Row row = rows.nextRow();
        String name = row.getValue("name");
    etc etc. Anyways, currently it sits on top of jdbc and is happy except for
    primary keys which are a bitch.
    Namespaces come back into play here to do:
    table.storeFromRequest( new ServletNamespace( request ) );
    etc etc.
    I'm not suggesting this is a good system, just to throw notice of my
    interest in your project into the pot.
    On 17 Dec 2001, Bryan Field-Elliot wrote:
    > Is there a (or plans for a) standardize Jakarta Persistence Framework?
    > I've built about 7 projects now on EJB, about 4 of them on top of Struts
    > as well. I consider myself an expert at EJB, and I'm also at the point
    > where I'm sick of it -- too overkill a framework, too much work to
    > establish your entity framework (CMP), and too much "black magic" under
    > the hood of your EJB server.
    > I've built my own persistence framework which, in my opinion,
    > accomplishes the important goals of EJB (from a web app developer
    > perspective), and strikes my own balance in terms of what's important in
    > a framework vs. not. Particularly:
    > - Tied to JDBC, vs. EJB's attempt to abstract it
    > - One class per entity, vs. EJB's 3-5 (Home Interface, Remote Interface,
    > Local Interface, Bean Class, and Primary Key)
    > - Implicit transaction wrapping at the Struts Action level (including
    > commit if the Action succeeds, and rollback if the Action throws an
    > exception).
    > - Explicit transaction rollback from the Struts Action if desired
    > - The same beans can be passed to the View (by way of Request attributes
    > or otherwise), where they become detached and read-only.
    > - ~90% of the framework is contained in a single class which any JDBC
    > developer should be able to read and understand (vs. EJB -- how many
    > classes are there in the JBoss project?)
    > - The design goal is, Keep It Simple and underStandable. If you need
    > EJB's more advanced features, then go out and use EJB.
    > - Data Caching at the app server level should be easy to implement
    > within this framework (a least-recently-used and/or a time-to-live
    > algorithm, using custom sizes and timeout values which make sense to the
    > developer).
    > Is there already a Jakarta persistence framework which roughly
    > accomplishes these goals? If not, is there interest in starting one?
    > Regards,
    > Bryan
    To unsubscribe, e-mail:   <>
    For additional commands, e-mail: <>

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