You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Cheng <jc...@upromise.com> on 2002/08/15 01:57:37 UTC
concerns about Struts
Hi struts folks,
Let me preface this by saying, I haven't played around too much with Struts
but I have used some homegrown web MVC frameworks that work in much the same
way (from a Controller perspective, anyway). So if I am missing something
obvious about Struts, that's why...
Anyway, I have a couple of concerns with Struts as a controller,
specifically the ActionServlet and Action classes, and would really
appreciate your insight.
1) "Object explosion" for large sites--1-to-1 mapping of URLs to objects can
lead to hundreds of small classes. It really bothers me that Struts
encourages this kind of situation. Although the DispatchAction helps a lot.
2) Meaningless method signatures, like execute(Mapping, Form, Request,
Response). All the methods look the same, regardless of what data they're
actually expecting. This often makes it necessary to go into the Java code
just to figure out what data a method uses. Not to mention losing
compile-time type checking.
I have been doing front-end web development since 1996, and doing it in Java
since 2000, and in all that time I have never built a presentation tier that
I would consider both large and clean. It just seems like as websites get
bigger and bigger (the site of the company I'm working at has 738 at the
moment) there is no way to avoid "throwaway" code (i.e. at least one method
per request that does little else but service that request). I got so sick
of it that I am no longer in web development, instead I concentrate on the
backend transaction processing.
Being a Java/OO purist, I really don't like it when 738 type-unsafe,
throwaway objects (or methods at least) make their way into the Java object
model. I have grown to recognize that large amounts of such code are
necessary in any large website, but if I can help it I would like to keep it
out of the Java source for the above reasons.
I have started writing some code that pushes the messy code out of Java and
into an XML file not unlike the struts config file. However, I've only just
begun really concentrating on this problem, and don't have any experience
working with Struts in the real world, so I was hoping to hear some thoughts
on the subject before sinking much more time into it.
Do you agree with my two complaints? If not, why? If so, can you think of
any way to ease the pain and stay within the Struts framework?
Thanks,
Joe Cheng
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: concerns about Struts
Posted by John Yu <jo...@scioworks.com>.
At 10:21 am 15-08-2002, you wrote:
>There are those of us who have to write webapps anyway, and don't get that
>option. And, in reality, web development is *much* cleaner than GUI
>programs -- have you ever looked at someone else's code based on Swing, or
>MFC, or ...? That's how I ended up on the web app development in the
>first place, instead of GUIs :-).
I got to disagree with this. Perhaps, the reason why webapps are much
cleaner than GUI apps is that so far (most) webapps haven't achieved the
kind of interactive-ness found in GUI apps and thus don't require that kind
of complexity in the code.
> > Being a Java/OO purist, I really don't like it when 738 type-unsafe,
> > throwaway objects (or methods at least) make their way into the Java object
> > model. I have grown to recognize that large amounts of such code are
> > necessary in any large website, but if I can help it I would like to
> keep it
> > out of the Java source for the above reasons.
> >
>
>And what's the alternative?
><snipped/>
>
>Show me a better approach than MVC and I'll happily switch. I've never
>found one.
I do see there're a few promising alternatives. Even I'm a dedicated Java
developer, I have to say I'm impressed by ASP.NET. The way they use
"webform inheritance" instead of MVC to achieve the similar kind of
modularization/de-coupling is impressive. (Anyway, at the core, both MVC
and webform inheritance are just different kind of the delegation.)
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Don't develop Struts Apps without it!"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: concerns about Struts
Posted by David Cherryhomes <dc...@yahoo.com>.
A few notes from a few responses:
> > 1) "Object explosion" for large sites--1-to-1 mapping of
> URLs to objects can
> > lead to hundreds of small classes. It really bothers me that
> Struts
> > encourages this kind of situation. Although the
> DispatchAction helps a lot.
> >
>
> 30 years of professional software development experience leads
> me to
> believe that 738 simple, easy-to-understand, separately
> maintainable.
> single purpose classes that follow a standard design pattern
> (in this case
> the GoF "command pattern") are a much better investment that
> one class
> with 738 branch points -- unfortunately very common -- or zero
> business
> logic classes because the business logic is intermixed with
> the
> presentation (a malady that is far to common in webapps).
>
As Dave Peckham pointed out, you can have multiple
pages/requests map to the same Action class. The question you
have to ask in doing this is this: where do I stop? You do not
want the entire app, but only a specific set of related
functions mapping to the same Action class. When we did this at
my shop, we had about 20 different possibilities across 5 pages.
This resulted in a horribly long if/else block, and to make it
more complex, some of the "ifs" would have to execute other
"ifs" (e.g., if it comes in blank, do the same as if it came in
as read unless parameter x is null, etc.). To address this, I
broke the "ifs" into individual methods, then simply used the
incoming "action" parameter and, using reflection, executed the
appropriate method (null or "" mapped to a default method). This
is a much more OO structured approach than an if/else statement
and allows for cross-method invocation.
> > 2) Meaningless method signatures, like execute(Mapping,
> Form, Request,
> > Response). All the methods look the same, regardless of what
> data they're
> > actually expecting. This often makes it necessary to go into
> the Java code
> > just to figure out what data a method uses. Not to mention
> losing
> > compile-time type checking.
> >
>
> My experience has been that the benefits of "sameness" far
> outweigh these
> costs. In particular, type checking is something that is
> easily toolable
> - you don't have to have the compiler do it for you.
>
> Speaking of tools, have you noticed the number of tools that
> are starting
> to take models of a business application, and generating them
> based on
> Struts? That can happen because the basic interactions are
> very simple,
> and very well defined.
>
It also allows for a much simpler and more efficient
subclassing. Instead of the subclass having to acquire the
resources from multiple places, it has them all passed into the
method.
> > I have been doing front-end web development since 1996, and
> doing it in Java
> > since 2000, and in all that time I have never built a
> presentation tier that
> > I would consider both large and clean. It just seems like as
> websites get
> > bigger and bigger (the site of the company I'm working at
> has 738 at the
> > moment) there is no way to avoid "throwaway" code (i.e. at
> least one method
> > per request that does little else but service that request).
> I got so sick
> > of it that I am no longer in web development, instead I
> concentrate on the
> > backend transaction processing.
> >
>
> There are those of us who have to write webapps anyway, and
> don't get that
> option. And, in reality, web development is *much* cleaner
> than GUI
> programs -- have you ever looked at someone else's code based
> on Swing, or
> MFC, or ...? That's how I ended up on the web app development
> in the
> first place, instead of GUIs :-).
>
I heartily agree. I've done enough GUI programming to know I
never want to do it again. I am currently working on a major
application rewrite from a client/server base to become a webapp
and the ease and speed of which web screens can be designed and
implemented is amazing. Using intelligent DHTML allows for our
webapp to be fully keyboard driven as well as mouse
supplemented, thus retaining the keyboard speed of a green
screen or client server app. The one thing GUI apps still have
over webapps is the ability to more dynamically respond to the
user without having to send/receive info to/from the server.
There are ways around some of this, but overall it is not quite
as nice as a GUI for some things. On the whole (anybody see
Austin Powers 3? I can't say on the whole without cracking up
now!!!), web programming is so much better than true GUI
programming that I'll never go back.
And by the way, everybody on my project is responsible for
programming the front end JSPs through the back end EJBs. I'm
amazed when people say that there are shops that can completely
segregate the two tasks (I can see some segregation, but not
total unless it's a very large and advanced shop that can
actually divide the workflow that well -- a concept that I still
find difficult to believe).
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: concerns about Struts
Posted by "Craig R. McClanahan" <cr...@apache.org>.
People like different ways of approaching software design and that's fine.
Nobody insists that you like Struts; I'll just throw in a little
historical perspective in intermixed responses below.
On Wed, 14 Aug 2002, Joe Cheng wrote:
> Date: Wed, 14 Aug 2002 19:57:37 -0400
> From: Joe Cheng <jc...@upromise.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: "'struts-dev@jakarta.apache.org'" <st...@jakarta.apache.org>
> Subject: concerns about Struts
>
> Hi struts folks,
>
> Let me preface this by saying, I haven't played around too much with Struts
> but I have used some homegrown web MVC frameworks that work in much the same
> way (from a Controller perspective, anyway). So if I am missing something
> obvious about Struts, that's why...
>
> Anyway, I have a couple of concerns with Struts as a controller,
> specifically the ActionServlet and Action classes, and would really
> appreciate your insight.
>
> 1) "Object explosion" for large sites--1-to-1 mapping of URLs to objects can
> lead to hundreds of small classes. It really bothers me that Struts
> encourages this kind of situation. Although the DispatchAction helps a lot.
>
30 years of professional software development experience leads me to
believe that 738 simple, easy-to-understand, separately maintainable.
single purpose classes that follow a standard design pattern (in this case
the GoF "command pattern") are a much better investment that one class
with 738 branch points -- unfortunately very common -- or zero business
logic classes because the business logic is intermixed with the
presentation (a malady that is far to common in webapps).
> 2) Meaningless method signatures, like execute(Mapping, Form, Request,
> Response). All the methods look the same, regardless of what data they're
> actually expecting. This often makes it necessary to go into the Java code
> just to figure out what data a method uses. Not to mention losing
> compile-time type checking.
>
My experience has been that the benefits of "sameness" far outweigh these
costs. In particular, type checking is something that is easily toolable
- you don't have to have the compiler do it for you.
Speaking of tools, have you noticed the number of tools that are starting
to take models of a business application, and generating them based on
Struts? That can happen because the basic interactions are very simple,
and very well defined.
> I have been doing front-end web development since 1996, and doing it in Java
> since 2000, and in all that time I have never built a presentation tier that
> I would consider both large and clean. It just seems like as websites get
> bigger and bigger (the site of the company I'm working at has 738 at the
> moment) there is no way to avoid "throwaway" code (i.e. at least one method
> per request that does little else but service that request). I got so sick
> of it that I am no longer in web development, instead I concentrate on the
> backend transaction processing.
>
There are those of us who have to write webapps anyway, and don't get that
option. And, in reality, web development is *much* cleaner than GUI
programs -- have you ever looked at someone else's code based on Swing, or
MFC, or ...? That's how I ended up on the web app development in the
first place, instead of GUIs :-).
> Being a Java/OO purist, I really don't like it when 738 type-unsafe,
> throwaway objects (or methods at least) make their way into the Java object
> model. I have grown to recognize that large amounts of such code are
> necessary in any large website, but if I can help it I would like to keep it
> out of the Java source for the above reasons.
>
And what's the alternative? Any web application needs to solve the same
basic problem set:
* Accept a request
* Convert the input request parameters/cookies/headers/et al to
something your programming language can deal with
* Based on some aspect of the incoming request, decide what
transaction to perform.
* Call the appropriate business logic (and if you prefer a
single switch statement with 738 branches, we can stop talking
now ... you'd be considered hopeless :-).
* Transform the result of performing some business transaction
into a response that either shows the user what happened and/or
sets up their next activity.
Show me a better approach than MVC and I'll happily switch. I've never
found one.
> I have started writing some code that pushes the messy code out of Java and
> into an XML file not unlike the struts config file. However, I've only just
> begun really concentrating on this problem, and don't have any experience
> working with Struts in the real world, so I was hoping to hear some thoughts
> on the subject before sinking much more time into it.
>
One trend you will see happening is less code having to be written. In
Struts 1.1, you see that DynaActionForm (talk about wasted code - nothing
is more boring than writing a form bean :-), and experimental integration
of XML processing pipelines such as the Stxx project. In the future,
you'll undoubtedly see additional ways to reduce the amount of tedious
steps.
But, a word of advice ... get over your aversion to 738 instances of a
common pattern ... it will do your presentation tier designs a world of
good :-).
> Do you agree with my two complaints? If not, why? If so, can you think of
> any way to ease the pain and stay within the Struts framework?
>
No, I don't agree. And not because you don't have legitimate concerns;
you haven't made any attempt to show us a better path (indeed, you have
said that you gave up on webapp design because you couldn't).
There is no perfect development methodology -- everything in life has
tradeoffs. Struts has become the defacto framework for serious webapp
development in Java because more than a few people find it useful (many
thousands of downloads per month). So, it's clearly not just me that
understands that the benefits *far* outweigh the costs.
> Thanks,
> Joe Cheng
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: concerns about Struts
Posted by David Derry <dd...@acm.org>.
----- Original Message -----
From: "Dave Peckham" <ja...@yahoo.com>
>
> > 2) Meaningless method signatures, like
> > execute(Mapping, Form, Request,
> > Response). All the methods look the same, regardless
> > of what data they're
> > actually expecting. This often makes it necessary to
> > go into the Java code
> > just to figure out what data a method uses. Not to
> > mention losing
> > compile-time type checking.
>
> I fear you're making a big deal over nothing here. The
> only real thing that you lose type checking on is the
> Form. It does kind of suck that you have to know what
> specific form to cast to. But, it's not that big a
> deal, IMHO.
>
I guess that here I both agree and disagree with you. I agree that he is
making a big deal over nothing, but I disagree that it sucks that you have
to know the type of ActionForm to cast to. Is this any different than
working with Java Collections; you have to know what type of Object (and
cast to that type) you are retrieving from the Collection? At least the
central controller doesn't have to be concerned with the actual type of the
ActionForm. As long as it IS an ActionForm, the controller is happy.
Although I will say that I do see Collections that take any kind of Object
as one of the weaknesses of Java. I really miss C++ template containers. I'm
really looking forward to seeing what will be added to Java in this regard.
Dave
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: concerns about Struts
Posted by Dave Peckham <ja...@yahoo.com>.
I'm sure the real brains will reply to this in more
detail. Here's my 2 cents:
> 1) "Object explosion" for large sites--1-to-1
> mapping of URLs to objects can
> lead to hundreds of small classes. It really bothers
> me that Struts
> encourages this kind of situation. Although the
> DispatchAction helps a lot.
I avoid the situation you describe by mapping multiple
URLs to the same action and using the "parameter"
attribute of the mapping to indicate the "command"
that the Action will execute. This is basically a
finite state model:
<action path="/customer/add" type="CustomerAction"
parameter="add"/>
<action path="/customer/delete" type="CustomerAction"
parameter="delete"/>
Then I just use a if/switch logic to do the right
thing. However if you do this to extremes, you end up
with one big action and no OO design. Maintaining
"high cohesion" is the key.
> 2) Meaningless method signatures, like
> execute(Mapping, Form, Request,
> Response). All the methods look the same, regardless
> of what data they're
> actually expecting. This often makes it necessary to
> go into the Java code
> just to figure out what data a method uses. Not to
> mention losing
> compile-time type checking.
I fear you're making a big deal over nothing here. The
only real thing that you lose type checking on is the
Form. It does kind of suck that you have to know what
specific form to cast to. But, it's not that big a
deal, IMHO.
I suppose Struts is like any other framework I've ever
used. It has it's share of shortcomings, but it beats
the pants off writing it myself :-)
Dave
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>