This made me think of a thought I had earlier. Folks developed things like Velocity and XMLC because jsp has given people more than enough rope to hang themselves. What if someone came up an analogous "Controller Template Language" that made it impossible to put business logic in your Action classes? It would somehow use an interface like what is being described here to talk to the business/persistence parts. I think that would be pretty cool.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 04, 2002 3: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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
