I've always thought of a DAO not as an Adapter pattern as what you are
describing, but as an external Table Gateway. BO interfaces and even
the implementing classes shouldn't need to know how to persist itself or
even what to persist to (XML, DB, IO). That is up to the implementing
Gateway.
I think a DAO should just extend the functionality of the business
object, IE add configurable methods to persist, modify, select, etc and
leave the actual O/R logic up to the database with views, triggers, and
stored procedures (I wrote a book on this last time someone posted this
same topic).
Here's how our open source DAO works:
Action.execute(ActionForm loginForm)
{
DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
Method login = daoBroker.createMethod("login",User.class);
try
{
conn = dataSource.getConnection();
User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
if (actual == null) throw new LoginException();
}
finally
{
SQL.close(conn);
}
}
The config for this DAO looks like:
<class type="org.apache.persistent.junit.User" tableName="tbl_user">
<field name="email" column="email" pKey="true"/>
<field name="password" column="password"/>
<method name="login">
<sql>
select * from tbl_user where email = ? and password = ?
</sql>
<input>
<param name="email" idx="1"/>
<param name="password" idx="2"/>
</input>
</method>
</class>
CRUD methods are automatically created at config time based on field
definitions. It works great and the BO's are just left as retainers of
state. If you need specialized operations like a persist only fields
that are changed, then the <method> can take in a class of type Method.
| -----Original Message-----
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Friday, October 04, 2002 5:33 PM
| To: Struts Users Mailing List
| Subject: Re: Persistence Framework Comparison?
|
|
|
|
|
|
| >My wish was for a persistence or a ADO interface, and interface only,
in
| >Jakarta or else where respected.
| >
| >If there were such an interface one could switch from JDO to ORB to
OJB
| >to EJB to Simper to DAORowset to xyz, assuming other followed the
| >interface. Let them compete.
| >
| >Such interfaces would have to be very light weight. (Ex: find(),
save(),
| >commit(), getProperty(""); setProperty("", Object))
| >
|
|
| Asking for interfaces to be defined for ADO or a persistence layer
seems
| like asking for interface definitions for 'Model' components.
|
| I'd argue that the better approach is to create interfaces based on
the
| business requirements of your specific project.
|
| For example, define an Interface for a customer record and call it
| 'Customer'. Then give it 'business methods' like 'getCustomerDetails'
or
| 'updateCustomerPhoneNumber'. Implement your Action class to act ONLY
ON
| THE INTERFACE METHODS.
|
| Then build 'Model' components that implement the Interfaces. This has
the
| effect of helping you keep code that is specific to a particular
| persistance layer OUT of the Action class. Then when you need to
switch
| persistence layers from JDBC to EJB (or to a web service or whatever)
your
| ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED.
|
| For example:
|
| Customer cust = new CustomerJDBCImpl();
|
| cust.updatePhoneNumber('1-800-IMA-NERD');
|
| Where Customer is an interface and CustomerJDBCImpl is a class that
| implements the Customer interface using a JDBC persistence layer.
|
| If you change persistence layers here, none of the code needs to
change
| in the Action class except you instantiate a different implementation
| class. Since the Action class operates on the Interface methods, it
| doesn't care.
|
| To summarize:
|
| - Leave persistence layer stuff out of Struts - it doesn't need
it.
| - Define your 'Model' components using Interfaces for each
project
| - Bury persistence layer stuff inside classes that implement
| the interfaces.
| - Then, make all the changes to your persistence layer you want
| and your Action classes (and form beans, etc) don't change.
|
| This is the basic idea of MVC - seperate Model from View from
Controller.
|
|
|
| I guess I think that one of the great strengths of Struts is ITS LACK
| OF TIGHT DEFINITIONS FOR MODEL COMPONENTS (DAO's, etc). This makes it
| flexible and allows you to define Model components based on the
'business
| rules' of the project - not based on what the framework recommends.
|
| Just my thoughts, for what they're worth -
|
| Kevin
|
|
| -------------------
| Kevin Bedell
| Author, "Struts Kickstart" - SAMS Publishing
|
|
|
|
|
| >>>
| >>>Really? I think Struts is quite good at what it does, and to me,
| >>>persistence seems to outside the scope of a web application MVC
| >>>framework.
| >>
| >>Agreed. Struts does what it does best - web MVC framework. What the
| >>original author of the comments (sorry, lost in my mailbox right
now) is
| >>looking for is what I would recommend happen on top of Struts.
Something
| >>that takes Struts, a proven OSS O/R framework, and some glue to make
| >>DB-driven Struts applications faster to develop.
| >>
|
|
|
|
------------------------------------------------------------------------
--
| -
| This e-mail message (including attachments, if any) is intended for
the
| use
| of the individual or entity to which it is addressed and may contain
| information that is privileged, proprietary , confidential and exempt
from
| disclosure. If you are not the intended recipient, you are notified
that
| any dissemination, distribution or copying of this communication is
| strictly prohibited. If you have received this communication in
error,
| please notify the sender and erase this e-mail message immediately.
|
------------------------------------------------------------------------
--
| -
|
|
|
| --
| To unsubscribe, e-mail: <mailto:struts-user-
| [EMAIL PROTECTED]>
| For additional commands, e-mail: <mailto:struts-user-
| [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
