Cool desgin!
One comment is that ... it might be a bit harder to make it OO/reusable
implementation. ("my" version has CRUD that uses reflection )
With a "single" interface there could be more reuse.
Curios, how do you do reuse?
.V
[EMAIL PROTECTED] wrote:
>
>
>
>
>>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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
