Struts is a Java MVC framework for building web applications on the J2EE platform.
How and where Struts fits in the big picture?
Presentation Tier Strategies Technologies used for the presentation tier can be roughly classified into three categories:
• Markup based Rendering (e.g. JSPs)
• Template based Transformation (e.g. XSLT)
• Rich content (e.g. Macromedia Flash)
We will start by introducing the two modes of designing JSPs - Model 1 and Model 2 architectures in the next two sections and then arrive at Struts as an improvement over the Model 2 architecture.
Model 1 Architecture
Let us illustrate the operation of Model 1 architecture with an example. Consider a HTML page with a hyperlink to a JSP. When user clicks on the hyperlink, the JSP is directly invoked. The servlet container parses the JSP and executes the resulting Java servlet. The JSP contains embedded code and tags to access the Model JavaBeans. The Model JavaBeans contains attributes for holding the HTTP request parameters from the query string. In addition it contains logic to connect to the middle tier or directly to the database using JDBC to get the additional data needed to display the page. The JSP is then rendered as HTML using the data in the Model JavaBeans and other Helper classes and tags.
Problems with Model 1 Architecture
• In Model 1 architecture, the presentation logic usually leads to a significant amount of java code embedded in the JSP in the form of scriptlets. This is ugly and maintenance nightmare even for experienced Java developers.
• Application control is decentralized in Model 1 architecture since the next page to be displayed is determined by the logic embedded in the current page. Decentralized navigation control can cause headaches.
Model 2 Architecture - MVC
The main difference between Model 1 and Model 2 is that in Model 2, a controller handles the user request instead of another JSP. The controller is implemented as a servlet.
Advantages of Model 2 Architecture
• Since there is no presentation logic in JSP, there are no scriptlets. This means lesser nightmares.
• With MVC you can have as many controller servlets in your web application. In fact you can have one Controller Servlet per module.
Why do we need Struts? (Controller gone bad – Fat Controller)
If MVC is all that great, why do we need Struts after all? The answer lies in the difficulties associated in applying bare bone MVC to real world complexities. In medium to large applications, centralized control and processing logic in the servlet – the greatest plus of MVC is also its weakness. Consider a mediocre application with 15 JSPs. Assume that each page has five hyperlinks (or five form submissions). The total number of user requests to be handled in the application is 75. Since we are using MVC framework, a centralized controller servlet handles every user request. For each type of incoming request there is “if” block in the doGet method of the controller Servlet to process the request and dispatch to the next view. For this mediocre application of ours, the controller Servlet has 75 if locks. Even if you assume that each if block delegates the request handling to helper classes it is still no good. You can only imagine how bad it gets for a complex enterprise web application. So, we have a problem at hand. The controller Servlet that started out as the greatest thing next to sliced bread has gone bad. It has put on a lot of weight to become a Fat Controller.
First Look at struts
In Struts, there is only one controller servlet for the entire web application. This controller servlet is called ActionServlet and resides in the package org.apache.struts.action. It intercepts every client request and populates an ActionForm from the HTTP request parameters. ActionForm is a normal JavaBeans class. It has several attributes corresponding to the HTTP request parameters and getter, setter methods for those attributes. You have to create your own ActionForm for every HTTP request handled through the Struts framework by extending the org.apache.struts.action.ActionForm class. Consider the following HTTP request for http://localhost:8080/App1/create.do?firstName=John&lastName=Doe. Suppose class MyForm extends the org.apache.struts.action.ActionForm class and contains two attributes – firstName and lastName. It also has getter and setter methods for these attributes. For the lack of better terminology, let us coin a term to describe the classes such as ActionForm – View Data Transfer Object. View Data Transfer Object is an object that holds the data from html page and transfers it around in the web tier framework and application classes.
The ActionServlet then instantiates a Handler. The Handler class name is obtained from an XML file based on the URL path information. This XML file is referred to as Struts configuration file and by default named as struts-config.xml. The Handler is called Action in the Struts terminology. And you guessed it right! This class is created by extending the Action class in org.apache.struts.action package. The Action class is abstract and defines a single method called execute(). You override this method in your own Actions and invoke the business logic in this method. The execute() method returns the name of next view (JSP) to be shown to the user. The ActionServlet forwards to the selected view.
How and where Struts fits in the big picture?
Presentation Tier Strategies Technologies used for the presentation tier can be roughly classified into three categories:
• Markup based Rendering (e.g. JSPs)
• Template based Transformation (e.g. XSLT)
• Rich content (e.g. Macromedia Flash)
We will start by introducing the two modes of designing JSPs - Model 1 and Model 2 architectures in the next two sections and then arrive at Struts as an improvement over the Model 2 architecture.
Model 1 Architecture
Let us illustrate the operation of Model 1 architecture with an example. Consider a HTML page with a hyperlink to a JSP. When user clicks on the hyperlink, the JSP is directly invoked. The servlet container parses the JSP and executes the resulting Java servlet. The JSP contains embedded code and tags to access the Model JavaBeans. The Model JavaBeans contains attributes for holding the HTTP request parameters from the query string. In addition it contains logic to connect to the middle tier or directly to the database using JDBC to get the additional data needed to display the page. The JSP is then rendered as HTML using the data in the Model JavaBeans and other Helper classes and tags.
Problems with Model 1 Architecture
• In Model 1 architecture, the presentation logic usually leads to a significant amount of java code embedded in the JSP in the form of scriptlets. This is ugly and maintenance nightmare even for experienced Java developers.
• Application control is decentralized in Model 1 architecture since the next page to be displayed is determined by the logic embedded in the current page. Decentralized navigation control can cause headaches.
Model 2 Architecture - MVC
The main difference between Model 1 and Model 2 is that in Model 2, a controller handles the user request instead of another JSP. The controller is implemented as a servlet.
Advantages of Model 2 Architecture
• Since there is no presentation logic in JSP, there are no scriptlets. This means lesser nightmares.
• With MVC you can have as many controller servlets in your web application. In fact you can have one Controller Servlet per module.
Why do we need Struts? (Controller gone bad – Fat Controller)
If MVC is all that great, why do we need Struts after all? The answer lies in the difficulties associated in applying bare bone MVC to real world complexities. In medium to large applications, centralized control and processing logic in the servlet – the greatest plus of MVC is also its weakness. Consider a mediocre application with 15 JSPs. Assume that each page has five hyperlinks (or five form submissions). The total number of user requests to be handled in the application is 75. Since we are using MVC framework, a centralized controller servlet handles every user request. For each type of incoming request there is “if” block in the doGet method of the controller Servlet to process the request and dispatch to the next view. For this mediocre application of ours, the controller Servlet has 75 if locks. Even if you assume that each if block delegates the request handling to helper classes it is still no good. You can only imagine how bad it gets for a complex enterprise web application. So, we have a problem at hand. The controller Servlet that started out as the greatest thing next to sliced bread has gone bad. It has put on a lot of weight to become a Fat Controller.
First Look at struts
In Struts, there is only one controller servlet for the entire web application. This controller servlet is called ActionServlet and resides in the package org.apache.struts.action. It intercepts every client request and populates an ActionForm from the HTTP request parameters. ActionForm is a normal JavaBeans class. It has several attributes corresponding to the HTTP request parameters and getter, setter methods for those attributes. You have to create your own ActionForm for every HTTP request handled through the Struts framework by extending the org.apache.struts.action.ActionForm class. Consider the following HTTP request for http://localhost:8080/App1/create.do?firstName=John&lastName=Doe. Suppose class MyForm extends the org.apache.struts.action.ActionForm class and contains two attributes – firstName and lastName. It also has getter and setter methods for these attributes. For the lack of better terminology, let us coin a term to describe the classes such as ActionForm – View Data Transfer Object. View Data Transfer Object is an object that holds the data from html page and transfers it around in the web tier framework and application classes.
The ActionServlet then instantiates a Handler. The Handler class name is obtained from an XML file based on the URL path information. This XML file is referred to as Struts configuration file and by default named as struts-config.xml. The Handler is called Action in the Struts terminology. And you guessed it right! This class is created by extending the Action class in org.apache.struts.action package. The Action class is abstract and defines a single method called execute(). You override this method in your own Actions and invoke the business logic in this method. The execute() method returns the name of next view (JSP) to be shown to the user. The ActionServlet forwards to the selected view.
