Front controller

The front controller software design pattern is listed in several pattern catalogs and related to the design of web applications. It is "a controller that handles all requests for a website", 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, Perl6, 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:

• Apache Struts
• ASP.NET MVC
• Cairngorm framework in Adobe Flex
• Cro[1] or Bailador[2] frameworks in Perl6
• Drupal
• MVC frameworks written in PHP. For example, Yii, CakePHP, Laravel, Symfony, CodeIgniter and Zend Framework
• Spring Framework
• Yesod (web framework) written in Haskell

Implementation

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

1. XML Mapping: files that map requests to the class that 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 realizes authentication by playing the role of delegating helper or initiate contact retrieval.	Dispatchers can be used for navigation and managing the view output. Users will receive next view that is determined by the dispatcher. Dispatchers are also flexible: they can be encapsulated within the controller directly or separated to another component. The dispatcher provides a static view along with the dynamic mechanism. It also uses the RequestDispatcher object (supported in the servlet specification) and encapsulates some additional processing.	A helper helps 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 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 that is used to adapt and convert the model into the suitable format.	With the collaboration of helpers, view displays information to the client. It processes data from a model. The view will display if the processing succeeds and vice versa.

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 three benefits for using front controller pattern.

• Centralized control. Front controller handles all the requests to the web application. This implementation of centralized control that avoids using multiple controllers is desirable for enforcing application-wide policies such as users tracking and security.
• Thread-safety. A new command object arises when receiving a new request and the command objects are not meant to be thread safe. Thus, it will be safe in the command classes. Though safety is not guaranteed when threading issues are gathered, codes that act with command is still thread safe.
• Configurability. Since only one front controller is needed in web application, the configuration of web applications implementation is largely simplified. The handler accomplishes the rest of dispatching so that it is not required to change anything before adding new commands with dynamic ones.

In terms of liability, front controllers that determine the following activities by searching the database or XML documents, performance might be decreased. 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 whole 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.

External links

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