Page Controllers and Front Controllers

There is a variety of opinion as to whether JSF uses a page controller pattern or a front controller pattern. I've personally managed to get by using the technology without knowing the answer to this burning question, but I confess to having got interested despite myself. After failing to locate a site that analyzed the matter to my satisfaction I decided to figure it out for myself.

Note that both patterns are specific controller implementation strategies within MVC. To refresh your architectural understanding, Model View Controller (MVC) is a way of managing interaction between a user of a system and the data and behaviour of the system. The Model is responsible for the data and behaviour; the Controller interprets user inputs; the View manages display of information. Both the Controller and the View depend on the Model.

For starters, here are some definitions of the Page Controller pattern:

Martin Fowler - An object that handles a request for a specific page or action on a Web site. Either the page itself or an object corresponding to it;

Microsoft - each dynamic Web page is handled by a specific controller. Possible use of controller base class.

Sun - doesn't apparently admit that there is such a thing in the J2EE world.

And here are some definitions of the Front Controller pattern:

Martin Fowler - A controller that handles all requests for a Web site;

Microsoft - single controller coordinates all of the requests that are made to the Web application. The controller itself is usually implemented in two parts: a handler and a hierarchy of commands.

Sun - The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies. Note: Sun also mentions typical ways of decomposing a complicated front controller.

Fowler mentions Application Controller in the context of front controllers: A centralized point for handling screen navigation and the flow of an application. Sun Java architects (for example, Alur, Crupi & Malks) mention the use of an application controller in conjunction with a front controller as well.

Now, what does JSF do? Well, no question but that the FacesServlet intercepts all requests. However, if you peruse the source code for a typical FacesServlet implementation class, it doesn't do much - create the Lifecycle and FacesContextFactory instances in init(), and then call execute() and render() on that lifecycle instance in the servlet service() method, obtaining a new FacesContext instance for each request to pass to execute() and render().

What actually does the navigation - assuming you haven't customized this - is the default NavigationHandler. Although even this is just acting on the result of an action and the rules defined in faces-config.xml. So some of your controller logic is embodied in the navigation rules and cases...the rest of it resides in the code you write in your managed beans, because that's what actually generates the outcomes acted upon by the navigation handler.

Now, is a managed bean - specifically one that hosts methods referenced in page component action attributes - a page controller, or is it a decomposed chunk of a conceptual application controller supporting the FacesServlet front controller? There is no shortage of authors who argue that JSF follows a page controller pattern, precisely because so much of the dynamic navigation is contained in objects that often have nearly a one-to-one correspondence with pages.

Nevertheless, we're faced with one inescapable fact - each request to a JSF page goes to FacesServlet, and the flow of execution is through a stack of other JSF classes. In particular, there is not a page controller for each page that is run by the server (this is the default ASP.NET model). So I would classify JSF as definitely using a Front Controller - it just so happens that identifying FacesServlet as being the controller is misleading, albeit technically accurate. It's really FacesServlet plus a whack of other stuff.

As an aside, the ASP.NET MVC framework uses the Front Controller pattern. The routing subsystem is sort of like FacesServlet, and then there are a bunch of user controller classes that act on requests that are routed to them. I consider this relatively new offering from Microsoft well worth checking out.