 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | DAO - Static Methods | DAO - Static Methods 2004-12-21 - By Marvin Toll
Back
I'm struggling a bit to understand the key points of the attached response.
1. What advantage does a factory add? For example, there is no need for
DAO factory caching capability for objects that can not be instantiated.
2. In an O/R Persistence application mentioned, the DAO's would not be
reusable for a JDBC or EJB application - in this case, they invoke methods
specific to the Toplink API. So the issue of a "DAO deciding how database
calls are made" should not be applicable. Right?
3. How do static methods "restrict the usage"? Static methods should be
as accessible as an instance method. Right?
A further point - in the application mentioned the DAOs are very light-
weight. Typically, all four standard CRUD operations can be performed
with ten (or less) unique lines of code.
Any elaboration on these notions?
_Marvin
-- --Original Message-- --
On Tue, 21 Dec 2004 15:15:12 -0500, R Riluvan wrote:
It would be better to have DAO as a private static member variable in a
factory instead of having static methods in DAO. DAO could decide how
database calls are made, but DAO cannot restrict how it is being invoked.
Having static method in a DAO restricts the usage of such method calls
accross the application.
-- --Original Message-- --
From: Marvin Toll [mailto:MarvinToll@(protected)]
Sent: Saturday, December 18, 2004 3:15 PM
To: J2EEPATTERNS-INTEREST@(protected)
Cc: Marvin Toll
Subject: DAO - Static Methods
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)
|
|
|
