struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Cherryhomes <dcherryho...@yahoo.com>
Subject Re: concerns about Struts
Date Thu, 15 Aug 2002 05:50:24 GMT
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:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message