You want to centralize and modularize action and view management.
- You want to reuse action and view-management code.
- You want to improve request-handling extensibility, such as adding
use case functionality to an application incrementally.
- You want to improve code modularity and maintainability, making it
easier to extend the application and easier to test discrete parts of
your request-handling code independent of a web container.
Use an Application Controller to centralize retrieval and invocation
of request-processing components, such as commands and views.
- Command Handler Strategy
- View Handler Strategy
- Transform Handler Strategy
- Navigation and Flow Control Strategy
- Message Handling Strategies
- Custom SOAP Message Handling Strategy
- JAX RPC Message Handling Strategy
- Improves modularity
- Improves reusability
- Improves extensibility
- Front Controller
A Front Controller uses an Application Controller to perform action
and view management.
- Service Locator
A Service Locator performs service location and retrieval. A Service
Locator is a coarser object, often uses sophisticated infrastructure
for lookup, and doesn’t manage routing. It also doesn’t
address view management.
- Command Processor [POSA1]
A Command Processor manages command invocations, providing invocation
scheduling, logging, and undo/redo functionality.
- Command Pattern [GoF]
A Command encapsulates a request in an object, separating the request
from its invocation.
- Composite Pattern [GoF]
A Composite represents objects as part-whole hierarchies, treating individual
objects and compositions of objects uniformly.
- Application Controller [PEAA]
Martin Fowler’s description of Application Controller [PEAA] seems
to focus on controlling a user’s navigation through an application
using a state machine, as described in the Navigation and Flow Control
strategy. However, the Application Controller [PEAA] and our documentation
of Application Controller have the same core intent.