Page vs Front Controller

MVC has been a tried and tested method of structuring your applications for a long time. Generally MVC mainly focuses on seperating model and view and less attention on the controller. Specially in rich client applications the view and the controller tends to lie close together. But in web applications this seperation is more critical since the view is essentially happening at client side (browser) while the most of the controller sits in the server side.
There are 2 basic ways of structuring the 'C' of the MVC, i.e Controller. The 2 basic methods are the Page Controller method and the Front Controller method.

The Page Controller is the more simple and straight forward way. Every request to the server is directed to a page (controller) of its own.

Under the Front Controller all requests will reach a single controller and it will dispatch the task to appropriate command class.

Let us analyze the 2 methods with respect to several aspects.

Criteria	Page Controller	Front Controller
Complexity / Ease of Implementation	Low complexity. Suits simpler web applications. Most of the time the commercial web application frameworks have built-in support.	Complexity is high compared to page controller. The single controller it self can be complex. However many CMS frameworks have this built in. (Eg: DNN)
Code Duplication / Code quality	Duplication can be high as the application grows. Has to implement a BaseController from which all page controllers extend.	Low code duplication. All common tasks can be put inside the front controller
Testability	Can be low. Has to go for a 2 part controller where one is HTTP dependant and the other is independant and testable.	The front controller will only handle transfer of the request to independant commands which could be testable. Has to be careful
Adaptability/Flexibility	When the pages of the web application is very different from each other, the code duplication can be higher. If you try to counter this with seperate inheritance tree, it can grow complex soon.	Since the front controller is centralized it's highly configurable. That's why many CMS frameworks use front controller to increase flexibility.
Performance	No extra bottleneck if plain page controller is used. However if a deep inheritance hierarchy is used performance can be a bit lower than normal.	The single front controller can end up being a bottleneck since it answers to all requests. Should avoid doing I/O or DB calls in the front controller as much as possible.
Thread Safety	The same page controller instance might handle (Depending on the web application framework, eg: ASP.Net) requests for the same page and thread-safety has to be considered. Use of static instances might be problematic.	Front controller can instantiate new command objects for each request and ensure thread safety at controller level. However model code still has to be thread safe.
Work distriubution and responsibility	Easier to distribute the work among developers since each area of work can be done completely seperately	Each developer has to have a good understanding of the Front Controller behaviour as everything depends on it.