The MVC design pattern is an object-oriented design pattern. It is not inconsistent with object-oriented encapsulation!
A Struts ActionForm is not part the model in an MVC application. It's really just an odd combination of the dismembered state of the controller and a dismembered partial state of the view. The model, for most Struts applications, is back in the EJB tier. Take a look at the link at http://www.jplates.com about scriptlets. It talks a lot about this common misunderstanding. Separation of *independent* concerns is a driving force behind a lot of object-oriented design patterns. But separation of object-state from the methods that should manage that state is a violation of object-oriented encapsulation. Dan Jacobs JPlates Inc. http://www.jplates.com > -----Original Message----- > From: Jones, Ted [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 10:50 AM > To: Struts Users Mailing List > Cc: [EMAIL PROTECTED] > Subject: RE: Object-oriented encapsulation in Struts - > merging Actions and ActionForms > > > That makes sense ...but wouldn't that break the MVC pattern > by moving the Controller function into the Model? > > Ted Jones > Maritz Inc. > [EMAIL PROTECTED] > http://www.maritz.com/ > > > -----Original Message----- > From: Dan Jacobs [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 10:40 AM > To: [EMAIL PROTECTED]; 'Struts Users Mailing List' > Subject: RE: Object-oriented encapsulation in Struts - > merging Actions and ActionForms > > > The kind of change I'm suggesting is not small or > incremental. It's pretty fundamental. > > Suppose you've got an ActionForm that represents the state of > some presentation object. It has no object-oriented behavior > at all. Just ways to read and write its fields. > > Now suppose you've got some Actions that are meant to do > things based on the ActionForm. They're like "C" functions > in that they just compute, and are not associated with any > instance data. They can access the equivalent of global data > from the session, but they're not really methods of objects. > > Now combine them. Define a class where the instance state is > basically the same as what was in the ActionForm, and that > defines methods that do the same things as were done by the > Actions. But instead of passing an ActionForm to an Action, > just invoke a method on an object. > > The rest of the implementation is a matter of reflection > tricks, and there probably has to be some additional > framework support to compensate for the lack of closures in > Java, and make the methods act like objects that conform to > some required interface. > > Does that make sense? > > Dan Jacobs > JPlates Inc. > http://www.jplates.com > > > -----Original Message----- > > From: David Graham [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 24, 2003 8:46 AM > > To: Struts Users Mailing List > > Subject: Re: Object-oriented encapsulation in Struts - > > merging Actions and ActionForms > > > > > > Specifically, what would you change? > > > > David > > > > --- Dan Jacobs <[EMAIL PROTECTED]> wrote: > > > [ potentially controversial topic ] > > > Hi all, > > > I have noticed that most of my Struts applications > > > end up being > > > implemented like dismembered objects. > > > > > > I design the controller parts of my Struts > > > applications using > > > object-oriented design techniques, but then I have > > > to transform my > > > designs into an awkward, non-object-oriented form: > > > > > > * What was originally encapsulated object state has > > > to be extracted > > > and isolated as ActionForms. > > > > > > * What were originally methods that acted on > > > encapsulated object state > > > have to become stateless processors in the form of Actions. > > > > > > * The Struts servlet acts like another > method-turned-C-function when > > > it resets and assigns property-values in the > > > ActionForms. > > > > > > I can translate in the other direction too. If I > > > take someone else's > > > Struts application, I can derive an effective object > > > model from the > > > relationships between the Actions and ActionForms > > > described in the > > > struts-config.xml file. That's really useful for > > > figuring out what's > > > going on. > > > > > > There's no problem getting all of this to work, and > > > the Struts servlet > > > and framework do some very useful things. But the > separation of the > > > Actions from the ActionForms makes it harder to > > > maintain the integrity > > > of the original object-oriented designs. > > > > > > What I'd really like to see is a truly > > > object-oriented approach to the > > > controller, where the state of the web-application > > > is encapsulated as > > > instances of real classes (not just the equivalent > > > of C struts) that > > > are acted on by methods. The methods would be > > > invoked just like > > > Actions are currently invoked, but rather than pass > > behavior-less data > > > to data-less functions, we could have methods acting > > > on encapsulated > > > object state. Who knows - maybe someday we could > > > even have subclasses > > > and inheritance and constructors and methods with > > > method parameters. > > > > > > If action-mappings could map to methods invoked on > > > named instances, > > > Actions and ActionForms could be merged into real > > > objects, and the > > > object-oriented character of controller designs > > > could be maintained. > > > > > > Is there any compelling reason that this shouldn't > > > be done? > > > > > > > > > I can get the object-oriented behavior I want using JPlates, but I > > > don't want to have to duplicate all of the other > contributions that > > > Struts offers for web-applications. I use JPlates > > > with Struts, but > > > I'd be happier with a more object-oriented version > > > of Struts. > > > > > > Dan Jacobs > > > JPlates Inc. > > > http://www.jplates.com > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Confidentiality Warning: This e-mail contains information > intended only for the use of the individual or entity named > above. If the reader of this e-mail is not the intended > recipient or the employee or agent responsible for delivering > it to the intended recipient, any dissemination, publication > or copying of this e-mail is strictly prohibited. The sender > does not accept any responsibility for any loss, disruption > or damage to your data or computer system that may occur > while using data contained in, or transmitted with, this > e-mail. If you have received this e-mail in error, please > immediately notify us by return e-mail. Thank you. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
