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. Fewer classes are required if this behavior is performed within the controller Servlet. 11. Struts applications, with their Action and ActionForm subclasses and the struts-config.xml file, add additional development and deployment complexity that may be too difficult for less experienced developers to grasp. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
