[OT]RE: Persistence Framework Comparison?

[David Graham <dg...@hotmail.com>]

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: Kevin.Bedell@sunlife.com
>Reply-To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>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:   
><ma...@jakarta.apache.org>
>For additional commands, e-mail: 
><ma...@jakarta.apache.org>




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [OT]RE: Persistence Framework Comparison?

[Jacob Hookom <ho...@uwec.edu>]

| -----Original Message-----
| From: David Graham [mailto:dgraham1980@hotmail.com]
| Sent: Friday, October 04, 2002 6:39 PM
| To: struts-user@jakarta.apache.org
| Subject: [OT]RE: Persistence Framework Comparison?
| 
| 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.

My implementation acts as a wrapper extending the functionality of an
object, you could say that it's the same as an Action in Struts.  Is
that poor programming? ;-)  Since you may add pre-compiled Methods via
the config, I chose this execution pattern to provide additional
flexibility in writing your own methods.  Plus I'm thinking of adding a
listener pattern to the methods to allow O/R mapping events to be passed
around the DaoBroker.

The User.class is being passed as the BO interface.  Dao's are stored in
a map under the class defined in the config.  So I may use
UserImpl.classs in the config, but if daos.get(User.class) returns null,
then it will search to see if the User.class is an interface of any Dao
and store an additional mapping for quick access next time.

| 
| 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

Jacob



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>