The Zuulcat Archives

This is going to be an unusual post for those of you that have read this blog earlier. Because this, this is going to be my first tech post (happy me).

Ever since I started developing GUI applications I have always had a bitter taste when writing UI code. In a way it makes me feel dirty. I have therefore always tried to stick to server-side and library programming, when possible, and distanced myself from all code that might have user interaction.

This week is very slow at work so I decided to investigate the possibility to do UI without doing UI (Do I sound crazy? Just bare with me). Since TDD is the new hype in the developer community I started looking for ways to make my UI testable through unit testing. I thought that if I can get the UI so abstract that it’s testable it can’t possibly still be dirty and I won’t have that horrible feeling that I have whenever I open the code-behind of an aspx page (chills I tell you, chills!).

I stumbled upon the Model View Presenter pattern. This, from what I understand, is a pattern to get a testable UI. But it also gives you a nice abstract layer between your UI and your domain objects. I won’t bore you with the details of the patter since there are loads of articles and blog posts that explain it better than I can do here.

I decided to redo an old program of mine with the MVP patter. The program is a calculator for the paper bag problem. I created it when I had a packing problem before I left for my vacation this summer. I needed to figure out how many stuff-bags 20x30cm I would need to fit 50l (dm3). I needed to know this because my backpack fits 50l and I wanted to organize all my clothes into stuff-bags. I found the solution for this problem on wikipedia (where else) and learned that the common name for this problem is the paper bag problem. Since I’m not a math wiz I opted to create a little console based program for calculating the volume of a flat container (paper bag).

Ok, so I started of by trashing the old program only saving the calculation bit and refactoring that into a testable class. Now I only had to do the UI. Since I couldn’t decide what kind of UI I would like I went ahead and started test-driving the presenter using a mocked view for the UI.

Once the presenter was finished I realized I had practically finished the whole program without even creating a UI project and I was a 100% certain all my code worked (TDD is your friend).

The process of adding a new UI is extremely simple once you have MVP implemented correctly. You just slap your view interface on the new UI and implement the methods, the rest is eye candy.

I quickly added a console based UI and hade it working within minutes. I then set of to create a win forms UI. Even though I had to modify the presentation logic a bit in order for the win forms UI to work properly, which affected the console UI, it was all done extremely fast (minutes I tell you, minutes). Now for the final test, adding an ASP.NET 2.0 UI. This was almost impossibly quick. I’m still in shock while writing this from the swiftness of the process.

When reviewing my code I found myself pleased with it. For the first time ever I could actually see myself having fun working with UI applications, even the validation was fun. The pros of the pattern are so many that I’m not going to rant about all of them here but what I see a especially great is that the UI logic is abstracted from the actual code. This makes creating new UI’s that use different technologies painless. And since all the UI’s use the same logic fixing a bug or changing functionality will effect all the UI’s making maintenance peachy.

Since the actual implementation of the UI and the logic of the UI are separated development can start without having a UI design. This allows the data and functionality to drive the UI design which is what we want anyway in most cases.

This separation also makes it easier for several developers to work on different parts of the application. Some can do the actual UI and some the logic while others drink coffee.

There is no actual end to how far you can stretch this. The pattern doesn’t imply that every UI component has its own view and its own presenter. A view can represent a set of functionality and a UI component can implement several views and have several presenters. This, for example, allows you to have a wizard in your win forms environment but choosing to place all the steps on a single page in your ASP.NET solution. It’s still the same UI logic!

But my favorite pro is that the raw UI code is kept to a minimum and is isolated to its own little hellish class, allowing me to work on the UI logic without actually doing UI (see I told you to bare with me).

The new, improved and totally over designed Paper Bag Problem Calculator can be downloaded here. It’s released under LGPL so if for any quirky reason you would want to use it in a commercial application your free to do so.