Dispatcher View Pattern

Dispatcher View keeps a controller focused on request handling and model preparation while a dedicated view handles rendering.

Why This Topic Matters

Why it matters in enterprise Java

Not every order screen needs a full orchestration-heavy workflow. Many just need controller-prepared data rendered clearly. Dispatcher View keeps that split clean.

Pattern Essentials

Intent, problem, and solution

Intent

What the pattern is trying to achieve

Separate request handling from rendering by having a controller dispatch to a view after preparing the model.

Problem

What goes wrong without it

Templates need controller-prepared data, but you do not want rendering logic mixed into the controller or business logic mixed into the template.

Solution

How the pattern answers the problem

Use a controller to gather data and dispatch to a dedicated rendering view.

Modern Relevance

Why it still matters now

This is still a common pattern in Spring MVC and similar controller-template stacks.

Structure

How the collaboration works

Controller receives request and loads view-relevant data.
Model gets prepared for rendering.
A view template renders the final output.
Business logic remains outside the view.

Java Example

Java example in the Order Management domain

Java example: account summary controller dispatching to a view

package org.javaomnibus.ecommerce.web;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public final class AccountController {
    private final AccountQueryService accountQueryService;

    public AccountController(AccountQueryService accountQueryService) {
        this.accountQueryService = accountQueryService;
    }

    @GetMapping("/account")
    public String account(Model model) {
        model.addAttribute("profile", accountQueryService.loadProfile());
        model.addAttribute("orders", accountQueryService.loadRecentOrders());
        return "account";
    }
}

Code Walkthrough

Step by step

The controller prepares the data the view needs.
Rendering is deferred to the template named by the controller.
Query work can stay in a query or application service rather than in the view.
The controller remains simpler than in a full business workflow screen.

Real-World Usage

Where this pattern shows up

Read-oriented account and dashboard pages
Pages where controller logic is present but not orchestration-heavy
Server-rendered views that need clean model preparation

When Not To Use

Cases where another shape is better

Deep business workflows where Service to Worker expresses the flow more clearly
API-only applications with no server-rendered views

Trade-Offs

Trade-offs and design pressure

Controllers can still become model-building dumps if query boundaries are weak.
Simple dispatch flows can gradually grow into orchestration flows and need refactoring.

Comparison Note

How this differs from nearby patterns

Dispatcher View is lighter than Service to Worker. Use it when the controller mainly gathers data and forwards, not when substantial business processing occurs.

Common Misuse

Mistakes to avoid

Adding transactional business work directly into the controller
Using the view to call services or repositories
Treating simple dispatch pages and complex service workflows as the same shape

Related concepts

Service to Worker View Helper Composite View