Presentation Logic Development Pitfalls

By this point, we have established a clear separation of responsibilities: state logic selects handlers, business logic makes decisions, and presentation logic visualizes the current state and exposes triggers.

This page looks at what happens when that separation is violated.

The most common presentation logic mistake is taking over responsibility that does not belong to it.

The Temptation

Consider the following screens from the “Health Card Verification” use case.

From a UI developer’s perspective, the flow seems obvious: if the user clicks “I do not have a health card”, the application should simply navigate to the “Additional Charges” page.

Many UI frameworks actively encourage this approach by providing direct navigation APIs between pages.

The Hidden Problem

When presentation logic performs direct navigation, it silently makes a business decision.

In this example, the decision “a patient declares the absence of a health card” is embedded directly in the UI flow.

This decision does not belong to presentation logic. It belongs to business logic, because it determines the next state of the business process.

What Goes Wrong

When presentation logic bypasses state logic and business logic, several problems appear:

• The business process flow becomes hard-coded into UI code.
• Changes to business rules require changes to presentation logic.
• Different UIs may implement the same decision differently.
• The execution pipeline of a transition is broken.

Over time, the system becomes rigid and difficult to maintain.

The Correct Flow

The correct responsibility of presentation logic is much simpler.

• Display the current state.
• Collect user input.
• Raise a trigger.

After a trigger is raised, the transition execution pipeline takes over: business logic evaluates the outcome, state logic selects the next handler, and presentation logic displays the new state.

Presentation logic never decides where the process goes next.

Why This Pitfall Is So Common

This pitfall appears frequently because UI frameworks are optimized for navigation, not for business process execution.

Without a clear mental model of states, transitions, and execution pipelines, developers naturally gravitate toward direct page-to-page navigation.

Recognizing this pitfall early helps preserve the separation of concerns established in previous chapters.

Table of Content Software Development Pitfalls Next: Business Logic Development Pitfalls

 

---

Business Process Programming in .Net
© 2004–2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.