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.
What happens when your view is a finer-grained component? For example, in a Windows Forms application, a Form instance is a coarse-grained view. What happens if you want to treat a UserControl instance as a view?
How easy is it for you to create another view layer for your application using a different view technology? For example, how easy is it for your Windows Forms application to also support a web view layer?
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.
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 . 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:
Use a generic bag for your model and forgo the benefits of a strongly-typed language.
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.
Firstly, it is a web only framework. That is, the views in your MVC application must serve up content over HTTP. That is fine if your application is web only, but what if you want to write a Windows Forms application? Or what if your application needs to support both web and other view technologies?
Secondly, like a lot of .NET ports, Maverick is aimed largely at developers moving to .NET from Java who have garnered a familiarity with the Java implementation of the framework. It might also be particularly useful if you’re porting a Maverick-based Java application to .NET.
Having said all that, I see no reason why you couldn’t combine the use of both Maverick.NET and Ingenious MVC in a web application. Maverick.NET excels in the area of transformations. You could set up your application such that Maverick.NET is used during view transformations, but Ingenious MVC is used for defining valid view transitions, associating controllers with views etcetera.
The Composite Application Block (CAB) is the latest framework offering from Microsoft. It is targeted specifically at aiding in the development of complex Windows Forms applications. To that end, CAB includes a lot of general application services that fall outside the scope of MVC. For example, it includes an event broker and command architecture.
The inversion of control (IoC) pattern is at the heart of the CAB and is implemented by the ObjectBuilder mini-framework. The ObjectBuilder makes heavy use of reflection in order to inject at runtime the various components and services your types need.