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 = store.open("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.
Bay
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
