Windows Forms Annoyances 2.

Continuing my previous post on what I don't like about the current implementation of Win Forms, I'll expand on a throwaway comment I made about MVC.

Win Forms doesn't really support MVC; the model MS favoured was the Document\View pattern, implemented in MFC, and later in Visual Basic.old. The benefits of this is that it eliminates the complexity of MVC (which relies heavily on eventing, pointers, and decouples your UI application into a user interface and an underlying object model - so good OO skills are a must).

So, when MS came to create WinForms, they pretty much took the existing VB model and development mindset and gave it a new gloss; as I said in my last post, this makes the transition for VB developers to Win Forms relatively trivial, but IMO it was a "warts and all" port; sure, there's some good stuff, but there's also a lot of nasy stuff that should really have been re-thought (see my last post for more on this). My main objection is that it is possible to do MVC in Win Forms, but by default you're pushed into the default document/view model.

So, when you come to create a Win Forms app, what do you do? First off, the IDE will put the app's entry point, Main(), in the default form (this is "fixed" in VS2005). You will then drag and drop controls onto this form, and in most cases double-click on them to add code behind the exposed events. Next, you decide you need data; so you'll make calls to a database, or web service right there in the event code in your form (or perhaps you'll show some initiative and create a class that wraps the call for data, but it really just amounts to the same thing). Perhaps some buttons or controls will navigate you to other forms; again, you'll instantiate and show those forms right there in your form's code.

Let's go a little deeper and look at two popular controls, the TreeView and ListView; in Win Forms, these are pretty much identical to their VB.old predecessors; you can quite easily add Nodes to a tree by clicking the Nodes property and using the little dialog that pops up - you can just "hard-code" the data right into the control - that's OK for prototyping, but it breaks MVC. While we're on the subject of patterns, let's take a look at the look & feel; don't like it? OK, so change the border style - oops, just 3 styles to choose from and no way to set the colour - time to subclass TreeView and use System.Drawing to create a custom border. What we should have seen here is the use of the Strategy pattern to allow new behaviour to be applied to the border property at runtime.

Why is this bad?

• You end up with your form having navigation code "hard-coded" within it; in the example above, what happens if you want to add a splash screen that shows before the default form is displayed? Some nasty code in the form_load event that hides one while showing the other?
• Your calls to fetch data are tightly coupled into your UI code; even if you have a separate class, a separate component, that does the dirty work of actually getting the data from a database or web service, it's still initiated from your UI (view) code.
• Your forms will get very, very big and unwieldy; and it's not just about the amount of code I'm taling about - the majority of your app's structure lies in its navigation graph and how it stores and manipulates data - and if it's all in your form code (see previous two bullets) then your app is going to get very hard to maintain very quickly.

Personally, I think this is the reason why so many VB apps are so difficult to maintain, change, and debug. MS have a write-up of MVC (albeit from a web-focussed perspective), and they have (predictably) added a caveat at the bottom indicating that Document/View is superior, which is no surprise considering that Win Forms and ASP.NET both utilise it. MS produced the User Interface Process (UIP) Application Block, to address this issue and bring MVC to .net UI dev; unfortunately, the UIP was excessively web-focussed, and it was hard to apply the navigation model to a thick client application (note that two new versions of UIP will be developed for Enterprise Library, one for web and one for Win Forms).