Front Controller

The Front Controller pattern channels all requests for a system through a single handler object that centralizes request processing before dispatching each request to the appropriate handler. It solves the duplication and inconsistency that arise when every endpoint independently implements cross-cutting concerns — authentication, logging, input parsing, error handling, and routing. Consolidating them in one entry point makes behavior uniform and changes easy.

How It Works

A single Front Controller receives every incoming request. It performs common pre-processing — parsing, authentication, authorization, logging, locale resolution — then consults a routing mechanism to determine which handler (often called a command, controller action, or view) should serve the request, dispatches to it, and finally applies common post-processing such as response formatting and error handling. Routing is frequently table- or annotation-driven so handlers can be added without changing the front controller itself.

The pattern is the backbone of most web frameworks: a dispatcher servlet, middleware pipeline, or router sits in front of all application code. Middleware chains are a modern realization, where ordered components wrap the dispatch to add concerns composably.

When to Use It

Use a Front Controller for any system that handles many requests sharing common processing — virtually all web applications and APIs. It is appropriate when you need consistent routing, centralized security and logging, and a single place to enforce policies across all endpoints. It also gives one location to evolve cross-cutting behavior without editing every handler.

It offers little for trivial single-endpoint services, and a poorly designed front controller can become a bottleneck or a god object if it accumulates too much logic instead of delegating.

Trade-offs

The pattern removes duplicated cross-cutting code, enforces consistency across all requests, and concentrates routing and policy in one maintainable place, making it easy to add concerns globally. It pairs naturally with middleware to keep that central logic modular.

The risks are centralization hazards: the front controller can grow into a monolithic chokepoint that is hard to maintain and a single point of failure, and it can become a performance bottleneck if heavy processing runs synchronously for every request. Careful delegation — keeping the controller thin and pushing real work to handlers and composable middleware — is required to avoid these problems.

Related Patterns

Front Controller is closely related to Facade, since both provide a unified entry point, but it specifically governs request dispatch and shared processing. It often uses Proxy- or Decorator-style middleware to layer concerns, and it dispatches to handlers commonly implemented with the Command pattern. The Mediator and API Gateway patterns share its centralizing intent at different scopes.

Example

A web framework routes every HTTP request through one dispatcher. The dispatcher authenticates the user, logs the request, resolves /orders/42 to the OrderController.show handler via a route table, invokes it, then serializes the result and handles any thrown error uniformly. Adding a new endpoint means registering a route and writing a handler; authentication and logging are inherited automatically because they live in the single front controller.