User:Qizhongzhi/sandbox

Front Controller

The front controller software design pattern is listed in several pattern catalogs and relates to the design of web applications. It "a controller that handles all requests for a Web site.", which is a useful structure for web application developers to achieve the flexibility and reuse without code redundancy.

Instruction

A typical front controller structure.

Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

The front controller may be implemented as a Java object, or as a script in a script language like PHP, Python or Ruby that is called on every request of a web session. This script, for example an index.php, would handle all tasks that are common to the application or the framework, such as session handling, caching, and input filtering. Based on the specific request, it would then instantiate further objects and call methods to handle the particular task(s) required.

The alternative to a front controller would be individual scripts like login.php and order.php that would each then satisfy the type of request. Each script would have to duplicate code or objects that are common to all tasks. However, each script might also have more flexibility to implement the particular task required.

Examples

Several web-tier application frameworks implement the front controller pattern, among them:

• MVC frameworks written in PHP. For example, Yii, CakePHP, Laravel, Symfony, CodeIgniter and Zend Framework
• Drupal
• ASP.NET MVC.
• Spring Framework
• Cairngorm framework in Adobe Flex.
• Yesod web application framework written in Haskell.
• Apache Struts.

Implementation

To better understand front controller pattern, there is an example to implement front controller in Java. It can be define in 3 components:

1. XML Mapping: files which map requests to the class will handle the request processing.
2. Request Processor: used for dealing with the request processing (and modifying or retrieving the appropriate model).
3. Flow Manager: first get the request and the output of the processing, then determine what will show on the next page.

Participants and Responsibilities

Controller	Dispatcher	Helper	View
The controller is an entrance for users to handle requests in the system. It can realize authentication by playing the role of delegating helper or initiate contact retrieval.	Dispatchers can be used for navigation and manage the view output. Users will receive next view which is determined by the dispatcher. Dispatchers also have flexible place: they can be encapsulated within the controller directly or can be separated to another component. The dispatcher can not only provide a static view, but can also provide the dynamic mechanism. The dispatcher uses the RequestDispatcher object (supported in the servlet specification) and encapsulates some additional processing.	A helper can help view or controller to process. Thus helper can achieve various goals. At view side, the helper collects data and sometimes stores data as an intermediate station. Before view's process, helpers serve to adapt the data model for it. Helpers will do certain pre-processes such as formatting the data to Web content or providing direct access to the raw data. Multiple helpers can collaborate with one view for most conditions. They are implemented as JavaBeans components in JSP 1.0+ and custom tags in JSP 1.1+. Additionally, a helper also works as a transformer which is used to adapt and convert the model into the suitable format.	With the collaboration of helpers, view can display information to the client. It processes data from a model. The view will display if the processing succeeds and will not display otherwise.

Demo implementation in Java

Here is part of a demo code to implement front controller.

private void doProcess(HttpServletRequest request,
                       HttpServletResponse response)
   throws IOException, ServletException {
    ...
   try {
      getRequestProcessor().processRequest(request);
      getScreenFlowManager().forwardToNextScreen(request, response);
    } catch (Throwable ex) {
      String className = ex.getClass().getName();
      nextScreen = getScreenFlowManager().getExceptionScreen(ex);
      // put the exception in the request
      request.setAttribute("javax.servlet.jsp.jspException", ex);
      if (nextScreen == null) {
         // send to general error screen
         ex.printStackTrace();
         throw new ServletException("MainServlet: unknown exception: " +
            className);
      }
   }

Benefits and Liabilities

There are several benefits for using front controller pattern.

• Centralized control. Front controller process all the requests to the web application. This kind of centralized control avoid using multiple controllers which is good for enforce application-wide policies such as using tracking and security.
• Thread-safety. A new command object arise when receiving a new request and the command objects are not meant to be thread safe. Thus, you will keep safe in the command classes. Though it does not guarantee safety when threading issues are gathered, code that act with command is still thread safe.
• Configurability. Since just one front controller is need in web application. This will simplify the configuration of implement web applications. The handler does the rest of dispatching so that we will not required to changing anything to add new commands with dynamic commands.

In terms of liability, front controllers that determine following activities by searching the database or XML documents, performance might be decreased badly. And implementation of front controller to existed systems always involving replacing the current ones, which makes it harder for beginners to start with.

Relationship with MVC pattern

1. In order to improve system reliability and maintainability, duplicated codes should be avoided and centralized when they are of the same common logic through the system.
2. The data for the application is better to be handled in one location, thus there will be no need to duplicate database retrieval code.
3. Different roles in the MVC pattern should be separated to increase testability, which is also true for controller part in the MVC pattern.

Comparison

Page controller is an alternative to front controller in MVC model.

	Page Controller	Front Controller
Base class	Base class is needed and will grow simultaneously with the development of the application.	The centralization of solving all requests is easier to modify than base class method.
Security	Low security because various objects react differently without consistency.	High. The controller is implemented in coordinated fashion, making the application safer.
Logical Page	Single object on each logical page.	Only one controller handles all requests.
Complexity	Low	High

See also

• Design pattern (computer science).
• Mediator pattern *Note: the front controller pattern is a specialized kind of mediator pattern.

Notes

• Alur, Deepak; John Crup; Dan Malks (2003). Core J2EE Patterns, Best Practices and Design Strategies, 2nd Ed. Sun Microsystems Press. pp. 650pp. ISBN 0-13-142246-4.
• Fowler, Martin. Patterns of Enterprise Application Architecture. pp. 560pp. ISBN 978-0-321-12742-6.
• Fowler, Martin. "Front Controller". Retrieved February 2, 2008.

External links

• Bear Bibeault's Front Man™, A lightweight Java implementation.

Category:Architectural pattern (computer science)