struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike <m...@michaelmcgrady.com>
Subject RE: Theoretical debate
Date Fri, 18 Jun 2004 14:22:28 GMT
+1  A lot of this discussion seems like it involves uses that don't need 
the levels of abstraction a true enterprise site must have.

At 07:19 AM 6/18/2004, DGraham@EvergreenInvestments.com wrote:

>1. This sounds like your test code (assuming you have some) is tightly 
>coupled with Struts.  You may or may not care.
>2. Not using DTO/VO means that your business layer is tightly coupled with 
>Struts.  This may or may not be a problem should you decide to use a 
>different controller framework.
>3. I'm guessing you're NOT using EJBs, otherwise, they would be tightly 
>coupled with Struts...
>
>Dennis
>
>
>
>"Frank Zammetti" <fzammett@hotmail.com>
>
>06/18/2004 09:42 AM
>Please respond to
>"Struts Users Mailing List" <user@struts.apache.org>
>
>To
>user@struts.apache.org
>cc
>Subject
>RE: Theoretical debate
>
>
>
>
>You know, kind of off-topic, but you remind me of a conversation I had with
>someone at work here, maybe you guys would have some input...
>
>I know what various patterns tell us we should do, but in practice... you
>guys of course have your ActionForms that transfer data from the view to the
>control layer... do you then have Data Transfer Objects, or Value Objects,
>or whatever terms you want to use, to hand off to your model layer?
>
>In other words, do you get data IN via ActionForm to an Action, then
>transfer all that data to another Data Transfer Object, then pass that off
>to some subordinate class to do the actual processing?
>
>I ask because most of the Struts apps I've seen don't bother with the DTO's,
>they just pass the ActionForm to the subordinate classes, or else pass them
>as parameters.  It seems that regardless of what literature is telling is we
>should do, in practice (GENERALLY), people don't bother with the DTO's.
>
>Have I just looked at the wrong apps?  What are most people doing in this
>regard?
>
>Frank
>
> >From: "Brian Lee" <brian_a_lee@hotmail.com>
> >Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
> >To: user@struts.apache.org
> >Subject: RE: Theoretical debate
> >Date: Thu, 17 Jun 2004 16:54:26 -0400
> >
> >I think struts' concept of separating your actions from your data is
> >admirable and should be followed. The concept of your value/transfer
> >objects (basically the form) also having business logic sounds acceptable
> >at first but rapidly becomes a nightmare when you try to use the same
> >value/transfer objects in multiple processes.
> >
> >I think it's a generally accepted practice that separating data from logic
> >is a "Good Thing"(tm).
> >
> >BAL
> >
> >>From: "Hookom, Jacob" <Jacob.Hookom@redline.mckhboc.com>
> >>To: 'Struts Users Mailing List' <user@struts.apache.org>
> >>Subject: RE: Theoretical debate
> >>Date: Thu, 17 Jun 2004 14:57:31 -0500
> >>
> >>I completely agree with what Crysalis is trying to push, also a framework
> >>called VRaptor (vraptor.org) also pushes the same idea of moving away from
> >>the procedural weight that Struts promotes.
> >>
> >>Look at JSF, do you have actions? No, JSF just updates your POJO beans and
> >>calls methods on them.  Why have an ActionForm or have to create all of
> >>these Actions that are simply getter/setter adapters?  Please don't be too
> >>quick to retort to my supposed anti-struts mindset, but there are other
> >>frameworks out there that allow direct interaction with my business
> >>objects
> >>and don't require a heck of a lot of framework specific coding.
> >>
> >>---
> >>
> >>Example:
> >>To have a multi-page form with JSF, I just create a bean that sits in
> >>Session scope that has a series of getters and setters.  JSF will also
> >>allow
> >>me to pre-set relationships to other objects at creation time.  Then, when
> >>I'm ready to submit the multi-page form, I just put in the jsp
> >>#{myFormBean.submit}.  No action mappings, only a managed bean entry.
> >>
> >>With Struts, I have to create an ActionForm objects (can't just use a
> >>business object I already have), and then create separate Action objects
> >>to
> >>manipulate that ActionForm.
> >>
> >>---
> >>
> >>-Jacob Hookom
> >>
> >>-----Original Message-----
> >>From: Frank Zammetti [mailto:fzammett@hotmail.com]
> >>Sent: Thursday, June 17, 2004 2:29 PM
> >>To: user@struts.apache.org
> >>Subject: Theoretical debate
> >>
> >>Last night I was Googling for something and I stumbled across the Crysalis
> >>framework.  I was actualyl intrigued by the underlying premise of it and I
> >>wanted to see what others thought about it.
> >>
> >>In a nutshell and in my own words, Crysalis
> >>(http://chrysalis.sourceforge.net/) has the underlying idea that when you
> >>develop in most MVC frameworks, Struts chief among them, you are actually
> >>doing something unnatural and in a way at odds with basic OOP design.
> >>
> >>Think about a shopping cart example... If you were going to write that in
> >>straight Java, not for the web or anything, how would you model it?  Most
> >>likely you would have a ShoppingCart class with a number of methods in it,
> >>things like addItem(), removeItem(), totalPrice(), etc.
> >>
> >>In Struts, although you aren't FORCED to, what you GENERALLY do is create
> >>three different Action classes like addItemAction, removeItemAction and
> >>totalPriceAction, and each is called in response to a form submission.
> >>
> >>But isn't it kind of odd that your object model isn't following what you
> >>probably think in your head is the right way, i.e., one class with
> >>multiple
> >>related methods?  Proper encapsulation and all that jazz, right?
> >>
> >>Well, Crysalis does just that.  It's controller elements are regular Java
> >>classes with multiple methods.  What you wind up with is something that
> >>resembles Remote Procedure Calls instead of numerous servlets as
> >>controllers.
> >>
> >>In other words, you would create the ShoppingCart object just as I
> >>described
> >>
> >>above, with all three methods.  Then, when you submit a form, the action
> >>is
> >>something along the lines of "ShoppingCart.addItem.cmd".  ShoppingCart is
> >>the class to execute, addItem the method and cmd is a suffix to direct the
> >>request, just like extensions in your Struts apps map requests to
> >>ActionServlet.
> >>
> >>The elements of the submitted form are treated as the parameters of the
> >>method being called, making it rather elegant.
> >>
> >>I haven't gotten into any real detail on Crysalis, but I was interested in
> >>getting other peoples' thoughts on the underlying principal (which I
> >>*THINK*
> >>
> >>I've stated properly!).  It was rather interesting to me because I'd never
> >>reall considered looking at it that way, and certainly it's not the way
> >>you
> >>typically approach a Struts-based application.  It was also interesting to
> >>me because I've for about four years now been preaching here at work that
> >>we
> >>
> >>should write our applications as a collection of services that are
> >>executed
> >>to form a coherent larger application, which is very much along the lines
> >>of
> >>
> >>this (so I guess I actually HAVE looked at it this way in a sense, but not
> >>exactly).
> >>
> >>Any thoughts?
> >>
> >>Frank
> >>
> >>_________________________________________________________________
> >>Watch the online reality show Mixed Messages with a friend and enter to
> >>win
> >>a trip to NY
> >>http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
>
>_________________________________________________________________
>Get fast, reliable Internet access with MSN 9 Dial-up – now 3 months FREE!
> > http://join.msn.click-url.com/go/onm00200361ave/direct/01/
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message