Better Design without ActionForm in Struts 2
Struts 2 is different from Struts 1 in many aspects. The intention behind changes in Struts 2 is to enrich this framework by adding new features, supporting web tier features like AJAX, and simultaneously simplifying the development with this framework. This framework change is also in line with current trend of getting job done using plain old Java objects (POJOs) instead of objects extending from framework classes. Providing container that can manage these POJOs without tightly coupling them with framework (e.g. extending classes from framework classes). When Struts moves to next level, it also expects the common application concerns like performance, maintainability, reusability etc. to be re looked with new approach. In this article, we are considering couple of important changes of Struts 2, and we are going to explore better design alternatives to ensure same reusability as that of Struts 1.
What are the Changes?
Web tier framework solves few important problems from MVC applications using plain servlets. If we recall the jsp-servlet pattern, then in service/doGet/doPost method are used to make n-number of calls to request object (request.getParameter()), to retrieve the value submitted from client. Second problem is of having common request handling code in each servlet. Most of the web tier frameworks abstract this request, response and navigation business to front controller, allowing servlet to handle functionality business only. Struts 1 is not different from these frameworks, it asks us to extend data form from ValidationForm class, and controller from Action class. These two classes can be used to transfer data between client and server, and implement functional request handling respectively.
The drawback with this approach was, tight coupling of these two classes with framework. Because of which these classes became useless for any use in other tiers (where we don’t require Struts).
In Struts 2, this problem is fixed. Struts 2 does not require classes to extend from framework classes unless there is any specific feature to be used (e.g. session object). Any POJO having execute method can work as an action class. Also, it does not require special class to handle data between client and server. Instead, the action class itself can be used to transfer the data. In this way, we are going back to the jsp-servlet model, isn’t it? Following diagram can summarize the technology transition.
What is Design Challenge?
As we are going to use a POJO with execute method to hold data as well as do the functional request processing, we are going to end up in a reusability issue in a most common scenario. Suppose we have customer management functionality involving add, search, update, and delete customer operations. If we have a pojo with execute method for each of these operations, then we will end up having AddCustomerAction, SearchCustomerAction, UpdateCustomerAction, and DeleteCustomerAction. As the customer attributes are common, each of them is going to have customer related attributes duplicated. This is where the reusability is going to be hampered and subsequently maintainability of these classes.
What are the Solutions?
There are two alternatives available. One involving plain object oriented concept, and other using Struts feature.
- Create and abstract class containing all attributes that customer require and extend all the action classes from it. We achieve reusability by having all customer attributes in single class, and also we achieve a design principle, which is one screen event mapping to one action class. This is how the class diagram will look like.
- Use Struts dynaAction feature. Create single POJO (say CustomerManagementAction)containing all customer attributes and methods addCustomer, searchCustomer, updateCustomer, and deleteCustomer. Map these methods as shown below.
<struts>
<package name="default" extends="struts-default">
<action name="*Customer" method="{1}" class="CustomerManagementAction">
<result name="success">/success.jsp</result>
</action>
</package>
</struts>
Summary:
Removal of tight coupling between Struts 2 and application has definitely increased reusability of objects across layers, but by using smart designs we can increase the reusability index further. These design alternatives applied as required definitely help to address this problem.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.