struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin.Bed...@sunlife.com
Subject Re: Persistence Framework Comparison?
Date Fri, 04 Oct 2002 22:33:15 GMT





>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>


Mime
View raw message