You are here

Separating the Application from the Environment

A useful pattern for developing testable rich client GUI applications is the *[Humble Dialog Box](* by Michael Feathers. I have used variations of it for *[TDD]( "Test Driven Development")* style development of all kinds of Windows programs. It boils down to have a rather dumb view (the humble dialog box) that delegates the handling of its events to a controller object. The controller does all the magic. It talks to the models and does whatever is necessary to react to the users gestures. When it is done it tells the view how to change its state. The view is mostly passive in this process. It receives events (user gestures), delegates them to the controller and receives updated data. It usually does not contain any logic besides what is needed to retrieve any event related data to hand it over to the controller. The controller talks to the view only through an interface. It does not know the concrete implementation of it.

With this approach it it possible to switch to a different GUI library or support multiple libraries in parallel without changing the controller. Use of this pattern enabled me to drive the design of the controllers and models by tests. It also let me migrate parts of an application from the older .Net Windows-Forms (SWF) to the more modern WPF library without even touching the controllers. All I needed to do was creating new WPF views, which called the same services of the controllers as their old SWF counterparts did. The controller would not know the difference as it did not know the difference between the tests that drove its design and the "real" views. Of course this also lets you use different GUI libraries "in parallel". The controllers and models are implemented once and can be used with different GUI libraries on different platforms.

For Web development I usually follow the *[Ports and Adapters](* pattern by Alistair Cockburn. Instead of having horizontal Layers stacked upon each other, having the user interface on top and the database on the bottom it puts the business layer(s) in the center and services like the UI and the DB on the outside. For each service need of the application there is a port and adapters that plug concrete services into those ports. E.g. there might be a persistence port and an MySQL adapter or an UI port and a Ruby on Rails adapter. A persistence adapter might be a database specific *[Repository](* and a UI adapter would be a controller in an MVC framework. There are multiple architectural patterns that are very similar. [The Clean Architecture]( by Robert Martin explains them in more detail.

Lately I was thinking about how I would implement *Ports and Adapters* with regards to rich client GUI applications and how it relates to the *Humble Dialog Box* and then it dawned on me. The *"Controller"* in the *Humble Dialog Box* is actually the application specific business logic, the *Interactor*, the *Control Object*. The views "code behind" is the UI ports adapter for the used GUI library. The term "Controller" was confusing me in this context, because with the usual MVC web frameworks I use the controller only as an adapter to the business logic. It does not contain any business logic itself.

It basically always comes back to separating the application from the environment. The details of the different approaches might differ, but the big picture is always the same.