Hi,
I've just finished building a prototype using Struts and talking to EJB
session beans at the back end and can give you a brief sum up of my own
practical experiences
without answering you point for point :
The chief adavantages are :
simplified error handling (some) / easy internationalisation / automatic
form handling - think of validation and parameter retrieval / ready-made tag
libraries for code-free JSPs / localisation of all action handling
Incidentally some of the disadvantages you list are trivial : almost every
servlet based framework I've worked with requires at least one class to be
programmed per action.
A Struts tip : think in terms of Actions not pages; so actions can be
reused by many pages
And.. Data entry validation can be toggled per JSP (per form actually; you
simply don't implement the validate method if you don't want it!)
Disadvantages are :
- only for JSP / servlets
- a relatively steep learning curve (but thereafter vastly improved
productivity)
- you're bound to the Struts tag libs if you use them (which you should). If
you ditch Struts you can start layouting again -:)
- (your point )internationalization is limited to static strings
Cheers
Anthony
PS
I only subscribed to this newsgroup today and the messages are all streaming
into my mailbox. I's there a !@#$%%%$#@ newsgroup where on can anser this
sort of thing using a normal newsgroup reader?
-Original Message-
From: David Bueche [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, October 31, 2001 2:23 PM
To: [EMAIL PROTECTED]
Subject: Feedback on Struts Pros and Cons
All,
I work with a company that is new to Java and we are evaluating tools for
a standard J2EE architecture. One of the Model 2 approaches we are
looking at is Struts.
After spending some time evaluating Struts, I have assembled the attached
list of pros and cons, but would like to get some impartial third party
feedback. If anyone sees anything I missed, I would appreciate your
insights.
Thanks!
-David
--
Struts Advantages:
1. Provides a controller ActionServlet that dispatches requests to the
appropriate business actions (Action subclasses) provided by the
application developer. All dispatching is defined in an XML file
(struts-config.xml).
2. Supports internationalization of messages and prompts.
3. Provides message collections that can be easily displayed in a
subsequent JSP/Servlet.
4. Allows the input (data entry) JSP/Servlet to be specified for each
Action subclass, so control can be returned to that JSP/Servlet in the
case of an error.
5. Provides custom tags to delegate many of the JSPs' HTML commands and
Servlets' println statements to tag libraries.
6. Automates population of the JSP domain object (ActionForm subclass)
with input data.
7. Allows data entry validation (ActionForm subclass) and business logic
(Action subclass) to be decoupled from the presentation JSPs/Servlets.
8. Data validation can be turned on or off in web.xml.
Struts Disadvantages:
1. Instead of direct dispatching by controller Servlet(s), dispatching is
defined in an XML file, adding a layer of indirection overhead to the
architecture.
2. Requires behavior typically factored for commonality in controller
Servlet methods to be duplicated in every Action subclass (some common
behavior could possibly be delegated to additional classes or components
and accessed by each Action subclass).
3. Struts internationalization is limited to static strings and does not
include internationalization of data returned by a business component.
4. Struts internationalization requires an ApplicationResources.properties
file, which conflicts with the current Enterprise Java Application
Standard of definely properties directly in the web.xml file.
5. Presentation of message collections is predefined in tag libraries
(although these could be modified for more specialized presentation).
6. Requires understanding of custom tags and tag libraries, as well as
their deployment. While this may not be a problem for more advanced
developers, this will add another layer of complexity for less experienced
development and support teams and requiring more intensive EAS
involvement.
7. Delegating much of the presentation layer to custom tags can make the
final HTML/presentation less clear than HTML placed directly in the
JSPs/Servlets.
8. Data entry validation is toggled on/off on a global basis only (not on
a per JSP/Servlet basis).
9. Requires recompilation and redeployment when data entry validation or
business component invocation changes. This is unnecessary if data entry
validation and business component invocation is performed in a JSP.
10. Requires at least one additional class per deployed page: an Action
subclass to invoke the corresponding business component or model behavior
and forward control to the subsequent JSP/Servlet.
