Im also using static method DAO's.
It's a good approach.
And internally using anonymous class to create the prep. stmt and execute
the query.

regards,
Manish

-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)
Sent: Tuesday, December 21, 2004 3:38 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: DAO - Static Methods


Have read somewhere on the net, but couldn't google it again, that static
classes are for utility methods and should not be used for executing
business operations. Using static methods makes the code procedural and is
not object oriented.

Technically, static DAO methods would work though.

Jayaraman




              Marvin Toll
              <MarvinToll@(protected):
J2EEPATTERNS-INTEREST@(protected)
              Sent by: An interest list     cc:
              for Sun Java Center J2EE      Subject: DAO -
Static Methods
              Pattern Catalog
              <J2EEPATTERNS-INTEREST@(protected)
              VA.SUN.COM>


              12/18/2004 02:14 PM
              Please respond to An
              interest list for Sun
              Java Center J2EE Pattern
              Catalog






Having recently participated on my first production implementation using
O/R Persistence (Toplink) - the team had an interesting design for DAOs.

A base abstract DAO class contained convenience methods and sub-classed
DAOs contained only static methods (with a private constructor). No DAO
Factory was required. Unit testing was conducted on the Application
Service objects - enabling Mock substitution of Business Objects as
needed. Both connection and transaction management were handled within
the Application Service objects and these resources were passed to the
DAOs as arguments.

What is interesting - is that the design decision for using static methods
was to promote/reinforce consistent use of stateless DAOs. In addition,
because the sub-classed DAOs were not instances - in effect, the Base DAO
static methods could be "overridden" by the sub-classed DAOs.

This is a different assertion for using static methods in DAOs then I've
previously encountered - and it worked very effectively for the team.

Any reaction to the notion of using static methods as a
convention/strategy for keeping state out of DAOs???

_Marvin

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)