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:35:37 GMT
On Mon, 2001-12-17 at 11:36, Craig R. McClanahan wrote:

    Having nice persistence frameworks is a good idea.  It's not clear to me
    that this is a "one size fits all" situation (although it might be).  But,
    it seems to me that it's mostly independent of the DynaBean discussions
    which are focused more on generalizing ActionForm (from a Struts
    perspective) and facilitating value objects -- I hadn't really considered
    it to be directly applicable to persistence layers.  Do you think it
    should be?

Per my prior postings -- in no way do I claim that a "one size fits all"
persistence mechanism can be built. Instead, what I'm interested in is
one which is tight, elegent, saves the user a lot of work, and fits
nicely with Struts.

I realize you may not have thought of DynaBeans in the context of a
persistence mechanism, but there seem to be some nice connections..

You're trying to make a nice Value Object system for Struts, and of
course a good persistence mechanism needs an easy way to break entities
off into Value Objects too (or, as the case may be, detach the original
bean from the database, enforce a read-only semantic, and voila, there's
your Value Object).

You also planned for registration of property change listeners -- this
would be useful in any "change detecting" persistence mechanism.

In short, I'd like to see what you come up with with respect to the
DynaBean, and then see what I can come up with in terms of layering a
simple persistence framework on top of it, and throw it in the Sandbox.
It would be nice to see one elegently designed system for shuffling data
all the way from the database, through Struts Actions and JSP pages, to
the user, and back again (through Struts Forms as well), in a way which
reduces the number of classes you have to build, yet still upholds the
ideas of MVC.


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