Here is a document I created for my manager. Most of the data is a stripped-down version detailing MVC for web applications from "Java Server Programming, J2EE 1.3 Edition." Hope it helps...
When using JSP pages to deliver dynamic content, a web application can use several design strategies to implement the front-end layer of the system. However, there are many factors that must be considered when choosing the most appropriate approach for the application being designed. Developers should be most concerned with maintainability and reusability of the components they are designing. Developers should also be careful not to include large amounts of
Java content (code) in JSP pages since this creates two problems. First, from a maintenance perspective, developers will have a hard time maintaining JSP pages containing large amounts of code mixed with markup since they can be difficult to read, and, more difficult for developers that are inexperienced with complex markup script. Second, from a page designer’s perspective, complex JSP pages may inadvertently be broken when the page designer tweaks the page’s look and feel aspects.
In general, when the above problems are encountered in any type of application utilizing JSP pages, it usually indicates a poor design. This type of design is commonly referred to as Page-Centric. In these designs, requests are made directly to the JSP page, and, the same JSP page produces the response. This also means that JSP pages are accessing enterprise data directly, such as data sources or Enterprise Java Beans. While this approach may be simple to implement since all processing logic is confined to the JSP, it does not lend itself to be scaled as application complexity increases.
JSP pages are more appropriate to use when they are involved in displaying markup only. This is because programmatic generation of markup from java code is very awkward, such as in a servlet. Similarly, servlets are much more appropriate for handling control and processing logic, such as in determining which page to redirect the user from a given request.
JSP pages consisting of mostly markup with limited amounts of Java code are easy to maintain and are usually referred to as the view component of a web application. A view is the representation of enterprise data. The state of this data is known as the model, and the model can be in the form of read-only JavaBeans. Since servlets are better served to handle request processing and control logic, they are referred to as the controllers or mediators of a web application.
Front Controller
Pattern The Front Controller pattern is an attempt to apply the MVC (Model-View-Controller) architecture to a web application. The MVC design pattern divides the components of a user interface into 3 modules. The model, which represents the data that the user is viewing, the view, which is the user’s window to the data, and the controller, which reacts to events generated from the user’s input.
Controller Servlet
The controller in this design is represented by a servlet that serves as the single entry point into the application. This controller maintains a map of sub-controllers. These sub-controllers are regular java classes that can manipulate session data, access enterprise data, and generate a link to the appropriate JSP view for displaying data. The sub-controllers are dynamically generated from a property resource when the controller servlet is first loaded. This allows the controller to be generic enough to be reused in other applications.
When a request is sent to the controller, the controller will determine -- via the request URL – the appropriate request handler (sub-controller) to process the request. All request handlers will implement a handleRequest(HttpServletRequest, HttpServletResponse) method, which returns a URL of the JSP view page to render the response. The controller will then redirect the user to the JSP using the URL returned from the request handler. This enables the controller to redirect the user without knowing how the request was handled by the request handling class.
Since there will exist one instance of the controller servlet, all application URL’s can be mapped to the controller using the web applications WAR web.xml file. Therefore, public URL’s will not physically map to actual JSP pages, instead they will all be mapped to and intercepted by the intermediate controlling servlet. The controller servlet does not concern itself about how to handle each request. Its main function is to decide which request handler class should be used to delegate the processing of the request.
Request Handlers (Sub-controllers)
Request handlers will process the request to determine the correct JSP view page to redirect the user. Unlike the controller, request handlers are application-specific; therefore, they should reside under the appropriate package-naming scheme that is application-specific as well.
When the controller selects the appropriate request handler to use for processing the request, the controller will invoke the request handler’s handleRequest(HttpServletRequest, HttpServletResponse) method. The request handler will then examine the contents of the request and determine which action to execute. The request handler can access the user’s session information and update any state that requires change. At this point, the request handler can also update any application state by accessing enterprise resources, such as EJB’s. It can also obtain any necessary data to be displayed and make this data available to the JSP view page using the session object or by setting attributes in the request. (The JSP view page can then access the display data by using <jsp:useBean> tags). Finally, the request handler must determine the page for displaying the data by choosing the correct JSP view page and returning the URL for this JSP page back to the controller. The controller will then redirect the request to the JSP.
Model
Simple Java objects represent the model, or data, in this architecture. The request handlers will obtain all necessary data to be displayed in a JSP view. The views will be given this data in the form of read-only Java Beans. These beans will not perform any type of markup generation of page processing. They only serve as the source of content for the JSP view to display.
JSP Views
The JSP view pages will be responsible for displaying the data contained in the model that was previously set by the request handler. These pages will contain no workflow logic. They will not have to examine any parameters in the request or make any choices to determine control logic for displaying data. The request handler will have previously performed all of the work. By using this approach, the JSP view can reduce the possibility of handing complex errors, such as those that might occur when accessing enterprise resources. Since the JSP view is accessing simple Java objects using <jsp:useBeans> tags, the page can render the content and display the markup without having to worry about handling error cases and redirecting the client to an error page.
Conclusion
While this approach may seem complex when compared to the Page-Centric design, the Front Controller pattern consists of more individual components, each with a clear and defined responsibility, which promotes code reuse and future maintainability. JSP pages will be easier to enhance and tweak for look and feel by page designers since they will contain very little Java code and will be easier to read by less-technical developers. The distribution of responsibility among the components in this application allows developers to work more independently of each other since there are fewer dependencies between request handling classes and JSP view pages using this architecture.
SAF
