I'm concerned about the piece of your code that returns a Method object. I
assume this is the Method class from the reflection package. It doesn't
strike me as a very good use of reflection and poor OO technique. Of
course, your code snippet doesn't show what you ultimately do with the
Method object.
Aspect oriented programming might suit your needs here and may be a cleaner
design. This isn't C where we pass around functions and execute them.
Dave
>From: [EMAIL PROTECTED]
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 19:27:35 -0400
>
>
>
>
>
>
>
> > I've always thought of a DAO not as an Adapter pattern as what you are
> > describing, but as an external Table Gateway. BO interfaces and even
> > the implementing classes shouldn't need to know how to persist itself or
> > even what to persist to (XML, DB, IO). That is up to the implementing
> > Gateway.
> >
>
>Adapter Pattern - I was trying to think of the name and couldn't. Thanks.
>
> > I think a DAO should just extend the functionality of the business
> > object, IE add configurable methods to persist, modify, select, etc and
> > leave the actual O/R logic up to the database with views, triggers, and
> > stored procedures (I wrote a book on this last time someone posted this
> > same topic).
> >
> > Here's how our open source DAO works:
> >
> > Action.execute(ActionForm loginForm)
> > {
> > DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> > DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> > Method login = daoBroker.createMethod("login",User.class);
> >
> > try
> > {
> > conn = dataSource.getConnection();
> > User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> > if (actual == null) throw new LoginException();
> > }
> > finally
> > {
> > SQL.close(conn);
> > }
> > }
>
>
> Looks very cool! Is this available somewhere?
>
>
> But back to my point - if you were to change over to using an EJB server,
> the Action classes would have to change. This short Action class isn't a
> big deal, but if you have long, complex forms that require multiple
>updates
> then there can be an advantage to putting an "Adapter" in front of the
> persistence logic.
>
> The adapter can shorten long Action classes and make them easier to
> read and maintain. But on the other hand, I guess you do have to create
> additional classes to use the adapter pattern, so it's a trade off...
>
> I think in the end, I prefer the approach that isolates the Action class
> from having to know what kind of persistent store it is using.
>
> This isn't to take away from the work you've done - it looks great.
>
> Again, just my views for what they're worth -
>
> Kevin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>---------------------------------------------------------------------------
>This e-mail message (including attachments, if any) is intended for the use
>of the individual or entity to which it is addressed and may contain
>information that is privileged, proprietary , confidential and exempt from
>disclosure. If you are not the intended recipient, you are notified that
>any dissemination, distribution or copying of this communication is
>strictly prohibited. If you have received this communication in error,
>please notify the sender and erase this e-mail message immediately.
>---------------------------------------------------------------------------
>
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
