Apr 2, 2007

.NET MVC Frameworks

Armed with the knowledge above, you might be tempted to dive head-first into the development of your next application. It is entirely possible for you to write an MVC application without the help of a framework. However, doing so will be much more tedious and time-consuming than using a good framework.

These are some of the questions your code will need to answer:

Before too long, you may find yourself writing your own MVC framework embedded in your application. If you are not careful, using the MVC architecture for your application may become detrimental rather than beneficial. Your application’s overall quality may suffer as a result of the increased work. Moreover, you will have to duplicate your efforts in the next MVC application you write.

With that in mind, let’s take a look at existing .NET MVC frameworks to see what they can offer.

The User Interface Processing Application Block (try saying that quickly) is an official Microsoft Application block for MVC application development. At the risk of sounding harsh, it is also definitive proof that you should never blindly use products simply because they come from Microsoft[3] . Version 2 is the latest version. See the resources section for a link.

UIPAB2 comes with a lot of problems, so let me point some of them out. Firstly, it is a constant battle writing an application with this framework. When something goes wrong (and it will, trust me), you will be lucky if you get a legible error message. Chances are you will have to step through the UIPAB code with a debugger to see exactly why it is failing.

Next up, UIPAB requires full type information to be specified for any of your views, controllers or whatever. For example, this will not work:

Instead, you have to provide all the information about the type:

As if that isn’t verbose enough, it would be more so if your assembly is signed. Worse, you cannot automatically increment your build number (as is the default when creating a project in Visual Studio) because it will no longer match your configuration file. You have to hard-code your version number and increment it manually, remembering to update your configuration each time you do so.

Alternatively, you will have to write a script to automatically update your configuration file based on your assembly’s version. Either way, it’s a pain and I have no idea why it was written this way.

The next problem I want to discuss is the UIPAB concept of state. UIPAB requires that you separate the state of your UI tasks out from their controllers. That is, it imposes restrictions on your model implementation. Specifically, it requires you to implement classes that inherit from its State class, or to use the State class as a generic bag. It does this only so it can facilitate automated persistence of your state.

So you have two choices when implementing your model:

  1. Use a generic bag for your model and forgo the benefits of a strongly-typed language.

  2. Implement your own strongly-typed state class which must inherit from UIPAB’s State class.

The problem with using the generic bag is obvious. You have to cast all your data when you get it out of the bag, and you lose the benefits of intellisense when accessing your data. Implementing your own custom state class is possible, but extremely tedious. You have to implement seven (yes, seven) constructors for each custom state class.

The other problem with the state concept is that each state class raises a single event for notifying other layers of state changes. This is simply not fine-grained enough for most serious applications. Granted, the event arguments can contain the key of the item that changed, but you’ll end up either refreshing your entire view with each state change, or with a big, dirty switch statement in your code deciding which parts of the view to refresh.

Hopefully this is enough information to steer you clear of UIPAB. Feel free to try it out yourself on a simple test application, but be very careful before you use it in a serious application. On the bright side, using UIPAB2 is what drove me towards writing Ingenious MVC.