commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Field-Elliot <bryan_li...@netmeme.org>
Subject Jakarta Persistence Framework?
Date Mon, 17 Dec 2001 17:11:16 GMT
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


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