 | 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 - PAO / PAOs ? | DAO - Static Methods - PAO / PAOs ? 2004-12-22 - By Marvin Toll
Back
The discussion has helped to bring to light that the DAO role is greatly
diminished in a non-JDBC non-EJB implementation - to the extent the term
DAO might introduce confusion. Unfortunately, I have experience with only
one O/R Persistence solution - so here goes.
In the unnamed application the DAOs do *not*:
1. Directly populate business objects (handled by Toplink).
2. Do not contain (or reference in the application codebase) any SQL - it
is either generated by Toplink or custom "named queries" have their SQL in
Toplink descriptor files.
So, what is left for DAOs to do (not much):
1. They invoke (via API0 Toplink to populate a business object.
2. They initialize a *new* business object with a primary key prior to
insert.
3. They register business objects for insert/update/delete as part of a
Transaction or "unit of work".
4. They invoke (via API) Toplink to execute queries (by query name).
5. They "close" a Toplink provided resource (which minimally includes a
Connection managed by Toplink).
So - it is in the context of a refined set of generalizable (read loosely-
typed base class convenience methods) DAO responsibilities that one could
assert static methods (and no factory) can effectively be deployed.
Perhaps a new pattern is warranted - PAOs - Persistence Access Objects.
_Marvin
-- --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)
|
|
|
