Presentation Logic Development Pitfalls

This chapter explains one of the common mistakes that occurs in almost all presentation logic developments – the incorrect use of the user interface role, when the user interface pretends to be business logic, taking away from it the very essence of its essence, which is making decisions about the target state of the business process.

Navigation between Pages

Let’s continue with an example from chapter “State Logic” where the information system displays, say, the page “1. Health Card Verification” to the user to verify the entered health card number. Let's also assume that the information system should display the page “2. Additional Charges” if the user clicks the button “I do not have health card”:

Typically, the code for navigation from the first page to the second is written inside the event handler for clicking the "I don't have a medical card" button on the first page. By writing the code this way, we introduce several destructive consequences:

· From an architectural point of view, we have completely abandoned business logic, since now the user interface defines the target state of the business process. That is, the user interface becomes business logic.

· From design point of view, we introduced dependency between two pages. Now the first page knows about the second page existence. And because pages reflect business process states, we introduced dependency between two states of the business process, which is nonsense because, as we learned in “States and Transitions” chapter, business process states are just periods of time not connected to each other with unique names that indicate stops in the business process.

· From a business perspective, we have frozen the business process within the written code on the first page. If a company needs to adopt a new way of doing business due to some changed circumstances (e.g. a law makes the use of a medical record optional, eliminating additional costs), but the software product does not support it, then the company has two options: continue doing business the old way, losing revenue, or rework part of the application, spending some revenue on it. In both cases, we have introduced a potential loss of revenue.

So, what is the right approach to designing simple navigation between two pages? We've already answered this question, but let's repeat it again - the right approach is a clear separation of concerns:

· The presentation logic should be responsible for managing all visual aspects of the business process, including providing the user with a set of clickable elements to initiate transitions from the current state of the business process to its defined target states.

· The business logic should be responsible for the process of selecting the target state of a business process according to business rules, performed after completing the analysis of the data collected in the current state of the business process.

In our case, as shown in the diagram below, the presentation logic should display a page "1. Check medical record" with a button "I don't have a medical record" on it to give the user the opportunity to notify the application that they don't have a health card. Click on this button would trigger the transition “A patient is declaring the absence of the health card”.

The pipeline of activities would send request to business logic which would switch the business process from the “Initial” state to the “The patient does not have a health card” state.

This state would be passed by the pipeline of activities back to the presentation logic, which would find the page registered for this state and display it to the user.

This way, a clear separation of responsibilities is achieved – each type of logic is responsible for its part of the transition of the business process from one state to another, and there are no dependencies between pages. As a result, we do not freeze the business process in the code written on the first page, since when the business requirements change, the business process can simply be reconfigured to display another page by registering this other page for the same state "The patient does not have health card".

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