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: [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]>
