struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. Cekvenich" ...@basebeans.com>
Subject Re: DAO and Struts Best Practice
Date Fri, 17 Jan 2003 17:17:13 GMT
I TOO am too dense to communicate it clearly sometimes:
But this is clear:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/ROOT/src/basicWebLib/org/commons/DAO

Take a look at the DAO interface;  and then a DAO implementation above.
(OT: The 2nd DAO implementation there will be using Commons SQL but not 
ready yet)

Static for me is the getting a hold of the connection pool so that gets 
done once, has nothing to do with getters/setters.
The parms are passed once.
Even a DAO.update() does not have parms, once can just do reflection and 
getmetadata, etc. genericaly.

But each bean (bean has getters/setters) has its own instance of DAO helper.

.V


Phase Web and Multimedia wrote:
> My struts app access my resource layer via a DAO pattern. I have been using
> DAO for a while and have seen various manners in which this is implemented.
> I have some questions for all of you out there in regards to the DAO pattern
> that you use and why. Following are some comparison points between a few
> patterns. What in your opinion are the pluses and minuses
> 
> Below I describe a few DAO patterns. If you have others feel free to append
> them:
> 
> Static Method DAO Pattern:
> - class is not instantiated
> - class use static methods
> - class contains multiple methods
> - each method contains it's own connection instantiation and destruction
> - parameters needed to perform each method's operation's are passed into the
> method
> 
> Instantiated DAO with Method parameters: (* This is the pattern I use)
> - class is instantiated
> - class methods are NOT static
> - class contains multiple methods
> - connection is a setter/getter and is shared among all methods during the
> life of the instantiated class object
> - parameters needed to perform each method's operations are passed into the
> method (no setters/getters)
> 
> Instantiated DAO Bean Pattern:
> - class is instantiated
> - class methods are NOT static
> - class contains multiple methods
> - connection is a setter/getter and is shared among all methods during the
> life of the instantiated class object
> - parameters needed to perform each method's operations are held on the
> class level as members of the class. They are altered with setters/getters.
> Each method receives no parameters.
> 
> The one method DAO:
> This pattern can be applied to all of the above. Essentially every class
> contains only one method that accomplishes a specific function.
> 
> I use the second pattern simply because during development I can see what
> parameters my method needs to perform it's funtion and make sure they are
> passed in. If I try to compile without providing the proper parameters the
> compile fails and I know my error before I start testing the class. It's
> simply a development things... easier javadoc and code completion as well.
> But, there have been times when I questioned the amount of parameters being
> passed into the method, but, rarely. My pattern does not easily lend itself
> to using tools like BeanUtils to perform property copying from one bean to
> another.
> 
> So, what are your thoughts.
> 
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> mail@phase.ws
> http://www.phase.ws



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message