I've actually never heard of DAO's described that way. I'm more familiar with terms like "Table Gateway" and "Row Gateway" patterns for DAO. If you are looking at using BeanUtils, then you want to look at creating a Row Gateway where you have beans that are "Gateways" to a single row, or only describe a single row instead of a whole table-- leaving you with finer grained entities to work with.
http://www.bookpool.com/.x/mc78r21de4/sm/0321127420 Jacob Hookom -----Original Message----- From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] Sent: Friday, January 17, 2003 10:16 AM To: Struts User List Subject: DAO and Struts Best Practice 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 [EMAIL PROTECTED] http://www.phase.ws -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
