Web Presentation Pattern Selector

Example 1 — Rails App with Fat Controllers

Scenario: A Rails e-commerce app (Rails 7, ERB templates, PostgreSQL) where product and order controller actions each contain pricing calculation logic, discount rule evaluation, and direct ActiveRecord queries. Developers report tests requiring full request stacks.

Trigger: "Our Rails controllers are too fat — business logic is in the actions and tests are slow and fragile."

Process: 1. Framework: Rails 7 — Front Controller (Router) already in place. Rails controller actions = Page Controller style. 2. Rendering: Server-rendered ERB — Template View confirmed. 3. No wizard flows → Application Controller not warranted. 4. Anti-pattern audit: Grep app/controllers/ for ActiveRecord queries and pricing logic in actions → found in OrdersController#create (82 lines, discount calculation) and ProductsController#show (direct SQL for related products). 5. Two Step View not needed — ERB templates + Rails application layout already handle shared structure. 6. Fix: extract OrderPricingService and ProductQueryService; controller actions become: decode params → call service → assign @result → render.

Output design record:

Example 2 — Spring MVC App Adding a Checkout Wizard

Scenario: A Spring MVC app (Java 17, Thymeleaf templates) with a working product catalog. Adding a 5-step checkout wizard: (1) cart review, (2) address, (3) shipping options, (4) payment, (5) confirmation. Steps may conditionally skip (digital products skip shipping).

Trigger: "We need to add a multi-step checkout. How do we structure the controllers and avoid scattered navigation logic?"

Process: 1. Framework: Spring MVC — DispatcherServlet = Front Controller already in place. 2. Rendering: Server-rendered Thymeleaf — Template View confirmed. 3. Wizard flow with conditional step skipping → Application Controller IS warranted. 4. Application Controller holds: step sequence definition, which service method per step, which view per step, skip conditions (digital product → skip shipping step). 5. CheckoutController becomes thin: delegate to CheckoutApplicationController.nextStep(session, input) → get command + view; execute command; forward to view. 6. Anti-pattern check: ensure no business logic in the Thymeleaf templates (th:if on business conditions is the scriptlet equivalent — move conditions to view model).

Output design record:

Example 3 — ASP.NET Core API Backend for a React SPA

Scenario: ASP.NET Core 8 Web API serving a React frontend. Team debating whether the "MVC pattern" applies — some say it's API-only so MVC doesn't matter.

Trigger: "We're building an API for our SPA. Does any of this web presentation pattern stuff apply to us?"

Process: 1. Framework: ASP.NET Core — middleware pipeline = Front Controller already in place. 2. Rendering: JSON API (no HTML). 3. MVC does apply to the API backend: Model = domain/service layer, View = JSON response shape (handled by serializer), Controller = API controller actions. 4. View pattern: Transform View — the JSON serializer/presenter walks domain objects and transforms them to JSON response DTOs. This is identical in structure to XSLT-based Transform View: input element types (domain objects) → output elements (JSON fields). 5. Controller pattern: Front Controller (ASP.NET Core pipeline) + Page Controller style actions in API controllers. 6. Application Controller: check for multi-step API flows (e.g., an onboarding flow across multiple API calls with server-side session state) — not present here → not warranted. 7. Anti-pattern note: "fat controller" still applies — business logic in API controller actions is the same problem as in HTML controllers.

Output design record: