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.
Ans: This is not from the perspective of DAO, but from the business objects - but it doesn't mean that DAO cannot be called directly from busines
DAOs those supply static/readonly data (e.g. retriving setup/configuration info from database) are good to be cached as an alternative to have static methods in dao.
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?
Ans: Yes I guess, do we need a DAO again against TopLink?
3. How do static methods "restrict the usage"? Static methods should be
as accessible as an instance method. Right?
Ans: In case if the same database call needed in another place within a user transaction, having a static method call be helpful in keeping the call within individual user transaction?.. In this case should the method be duplicated, one - a static call and another an object level call?. If the method defined to the object level, it is easy to make static reference by declaring a static member instance of the DAO (provides dual usage) (similar that of the Answer to question #1).
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?
Ans: Right, Factory classes may make use of the DAOs to make simple data access calls to construct objects, here is how Factory classes use DAOs. It would'nt be a good idea for a Business object to call DAO directly to retrieve set of objects, but to delegate such complex works to the Factory would be good. (IMHO).
Any thoughts?..
Thanks
S RIluvan.
----Original Message Follows----
From: Marvin Toll <MarvinToll@GTCGROUP.COM>
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM,YourFirstName YourLastName STOP MORE SPAM <rilwan22@HOTMAIL.COM>
CC: Marvin Toll <MarvinToll@GTCGROUP.COM>
Subject: Re: DAO - Static Methods
Date: Tue, 21 Dec 2004 19:58:44 -0700
Received: from swjscmail2.java.sun.com ([192.18.99.108]) by mc7-f38.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 21 Dec 2004 19:11:49 -0800
Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107])by swjscmail2.java.sun.com (Postfix) with ESMTPid 79768211C0; Tue, 21 Dec 2004 20:04:00 -0700 (MST)
X-Message-Info: JGTYoYF78jGF2bKabx8IKVC0rtVzbJSh
Return-Path: MarvinToll@GTCGROUP.COM
X-OriginalArrivalTime: 22 Dec 2004 03:11:49.0530 (UTC) FILETIME=[FA37E7A0:01C4E7D3]
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@GTCGROUP.COM]
Sent: Saturday, December 18, 2004 3:15 PM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
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@java.sun.com
From owner-j2eepatterns-interest@JAVA.SUN.COM Wed, 22 Dec 2004 07:03:07
Return-Path:
