struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Hookom" <hooko...@uwec.edu>
Subject RE: Persistence Framework Comparison?
Date Fri, 04 Oct 2002 23:18:01 GMT
I wrote it one weekend to get ready for a project (packages are named
org.apache.persistent.*); I can send you the original code with a sample
Main if you are interested.  I wrote it such that I could donate it to
Jakarta possibly, but I'm not familiar with the procedures involved.

| -----Original Message-----
| From: news [mailto:news@main.gmane.org] On Behalf Of V. Cekvenich
| Sent: Friday, October 04, 2002 6:11 PM
| To: struts-user@jakarta.apache.org
| Subject: Re: Persistence Framework Comparison?
| 
| Is it free? Where can I "download" this?
| Is there a sample?
| 
| .V
| 
| 
| Jacob Hookom wrote:
| > 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: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
| > | 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-
| > | unsubscribe@jakarta.apache.org>
| > | For additional commands, e-mail: <mailto:struts-user-
| > | help@jakarta.apache.org>
| 
| 
| 
| 
| --
| To unsubscribe, e-mail:   <mailto:struts-user-
| unsubscribe@jakarta.apache.org>
| For additional commands, e-mail: <mailto:struts-user-
| help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message