Many tools (especially on the Microsoft platform) make it easy to start your new project by just dragging and dropping some controls on a window. Just add some logic to event handlers in the window-class that represents that window and be done with it. Most programmers who have done this a few times will know that the result will probably an unmaintainable and untestable mess. UI patterns solve this problem by splitting up your application in different parts, each with their own responsibilities. The first part of this series will look at how different UI patterns divide responsibilities between their components

Let’s say you started building your application the way I described just now. You created a window, added some buttons and other controls and built some nifty logic in the event handlers behind the window. Your users are happy with your application so you get more time to add features. You add some more windows, some more controls and some more logic. But it doesn’t take long for you to notice that much of the logic is repeated between windows. Maybe you’d be better off putting that stuff, often called ‘business logic’, ‘domain logic’ or even just ‘the model’ into a set of separate classes. Seems like a logical choice right? Microsoft thought so when they built their MFC library. So they thought up a name for this ‘pattern’. They called it document-view.

Two part presentation

The MFC document-view pattern is the only ‘official’ UI pattern I know of that consists of only two components but I’ve seen many ‘unofficial’ architectures that used this same division. Let’s look at it a bit closer.

By separating ‘behavior that makes sense in the whole application’ (or ‘domain logic’) from ‘behavior that makes sense in a single window’ (or ‘presentation logic’) we can make our application a whole lot more maintainable. Domain logic isn’t repeated between windows (or ‘views’) anymore so we can make all changes in just one place. And when we do things right we can even test our domain logic without starting the whole application. What I mean by doing things right will become clear in the next article where I talk about how all these components talk to each other.

Very simple applications often don’t have a lot of presentation logic. Here two-part presentation makes a lot of sense. But now that computers have become a lot more powerful people expect more interactivity. Just putting text in textboxes and grids and pushing data back to the model when the user clicks ‘ok’ isn’t enough anymore. Unfortunately this causes our views to become a complicated mess. The next logical step is to split out the presentation logic from the view. Resulting in three part presentation

Three part presentation

The step from ‘big blob presentation’ to two part presentation was mainly motivated by the DRY principle. We were repeating domain logic between windows, by separating this out we could reuse it between windows and get rid of this repetition. As a bonus our application became more maintainable and more testable in the process. The next step will be splitting out presentation logic from the view. This step might be a bit less obvious because there is no repeated code to separate, but the maintainability and testability bonuses are still there. We have a separate presenter or controller that’s just concerned with our presentation logic and a thin view that acts as a translation layer between our code and the UI-framework we’re using.

Almost all UI patterns use a structure much like this. MVC, MVP, MVVM and all variations on these divide responsibilities between their components in this way. I started this series of posts to try to clarify the differences between different UI patterns. But just looking at the structure isn’t enough. The real difference lies in how these components interact. This is something we’ll look at next time.