Mvc And Request Handling

MVC and Request Handling

Purpose

Keep the web layer to its actual job — turning a request into a call and a result into a response — and put shared request concerns in one place instead of in every handler. Modern frameworks implement these patterns for you, so the value here is not in building them but in recognising which pattern a piece of code is playing, and noticing when a responsibility has landed in the wrong one.

The vocabulary, disambiguated

"Model" means three different things in a typical discussion, and conflating them causes real design errors:

Domain model        the business objects and rules (domain-logic-organization)
Presentation model  what the view needs: already formatted, already decided
Framework model     the map of attributes handed to a template (Spring's Model)

The separation used here for a web boundary:

Controller   interprets the request, invokes the application, selects the response.
             Delegates business rules and use-case transaction ownership.
View         renders. Owns no decisions beyond presentation.
Model        application state/behavior in MVC's broader vocabulary;
             prefer a deliberate presentation model at the response boundary.

Web MVC is not the original Smalltalk MVC: there is no observer relationship and no long-lived view. The name persists; the mechanism is request → controller → model → render.

Page Controller and Front Controller

Page Controller      one handler per page or action. Simple, local, and every
                     shared concern needs a shared mechanism such as filters
                     or composed collaborators.

Front Controller     one entry point receives every request, applies shared
                     concerns, and dispatches to a handler. Shared concerns
                     exist once; the handler stays small.

Many Java web frameworks provide a Front Controller (for example Spring's DispatcherServlet), and handler methods play the page/action role behind it. These patterns can coexist. The practical questions are which concerns belong in the front controller's chain and which in the handler, and whether the chain's stages are being used correctly.

Workflow

1. Check the handler's contents and runtime. Inspect routing, security configuration, Java and framework versions first. Examples use Servlet Spring MVC; ProblemDetail requires Spring 6+ (Java 17+), not an implicit upgrade. A controller should bind input, invoke application behavior, and map the result. Trace business rules and transaction ownership; a simple read need not gain a pass-through service (layering-and-boundaries).
2. Find duplicated policy. Repetition count alone does not justify indirection; shared authorization, error mapping, correlation, tenant and envelope semantics often belong in the chain when centralization prevents drift and preserves ordering.
3. Place it at the right stage. Filter, interceptor, argument resolver, exception handler, advice: they see different things and run at different times. Choosing wrongly produces a concern that works until it does not.
4. Extract flow decisions. If a handler decides which step comes next based on application state, that is an Application Controller and it belongs outside the web layer.
5. Keep the response shape a deliberate decision, not the accidental serialisation of whatever the service returned (remote-facade-and-dto).
6. Test at the right level. Handler tests should not need a database; the mapping, validation and status codes are what the web layer is responsible for.

Decision rules

A concern applies to every request (correlation id, security context,
request logging, tenant resolution)
        → the front controller's chain: a filter, before routing.

A concern applies to a group of handlers and needs to know which handler
was selected (authorisation on an annotation, feature flags per route)
        → enabled method security for authorisation; an interceptor can
          handle non-security route metadata. Keep request security in
          the security filter chain, with consistent path matching.

A concern turns an exception into a response
        → consistent error mapping at each boundary: MVC advice for MVC
          exceptions, security/filter/container handlers for their failures.
          Share the contract; avoid duplicated generic catches.

A concern turns request data into a domain-shaped parameter
(the current user, a parsed range, a tenant)
        → an argument resolver. This removes the boilerplate without
          hiding a business rule.

The next step of a multi-step flow depends on state, not on a link
        → Application Controller: a class that owns the flow, outside
          the web layer, testable without HTTP.

A screen is one page, one action, no shared concerns beyond the global
ones
        → a plain handler. Do not build a flow abstraction for it.

The API is REST over resources
        → routing is by resource and method, not by page. Page
          Controller and Front Controller both still describe what the
          framework does; the patterns to reach for are Remote Facade
          and DTO, not Two Step View.

Rules

• A controller deciding domain policy is a layering defect; if itself is not evidence because protocol negotiation, optional input and response mapping legitimately branch. Trace whether the condition must hold for non-HTTP callers.
• A controller with a repository call is not automatically wrong. For a pure read it can be the honest design; for anything that writes, it puts the transaction boundary and the invariants in the web layer (service-layer-design).
• Cross-cutting concerns implemented per handler can diverge. Repeated policy plus observed drift or ordering/security risk is the signal, and consider a shared chain stage or collaborator before a base controller: Java's single class inheritance makes independently varying base-class policies awkward to combine.
• Choose the chain stage by what it must see. Ordinary Servlet filters run before MVC handler selection. Interceptors see the selected handler but are not a sufficient security boundary: Spring warns of path-matching mismatches. Use the security chain and enabled method security; test uncovered routes and alternate dispatches.
• The framework's model map is a presentation concern. Putting entities in it couples the template to entity properties and can trigger lazy loading during rendering (orm-behavioral-patterns).
• Validation splits in two and both halves are needed: syntactic (required, format, range) belongs at the boundary, on the request type; semantic (this customer may not order this product) belongs in the domain, where it can be enforced regardless of the caller.
• One deliberate error contract across the application's HTTP boundaries. RFC 9457 problem details give a standard target (rpc-and-api-contracts).
• Application Controller is the least-known pattern here and the most useful where it applies: multi-step flows, approval chains, state machines. Its value is that the flow becomes a testable object rather than a set of redirects spread over handlers.
• Do not map classical page-flow patterns onto an HTTP API by analogy. An API may expose resources, commands, workflows and hypermedia; Remote Facade is useful when network granularity requires it, not a synonym for every REST endpoint (remote-facade-and-dto).
• Handler tests cover binding, validation, status codes and error shape with application doubles where useful. Separate integration tests may legitimately include a database to verify transaction, authorization or serialization behavior (architecture-testing).

Return the observed responsibility/ordering issue, the proposed placement and its evidence, and the focused checks performed or still needed. Missing configuration makes claims about filter coverage, authorization and transaction scope conditional; inspect it before diagnosing.

References

• Page Controller versus Front Controller — both patterns in a modern stack, exactly which shared concern belongs at which stage of the chain (filter, interceptor, argument resolver, advice) with the ordering that matters, the base-controller anti-pattern, and how the same reasoning applies to a message consumer or a scheduled job. Read when placing a cross-cutting concern or reviewing a controller.
• Application Controller — flow logic extracted from handlers: a state machine over an application process, where the flow state lives, how it is tested without HTTP, and when a flow abstraction is overkill. Read when a wizard, approval chain or multi-step process is being built or has become unmanageable.