Microsoft MVC and flow control

I have been involved in several projects that utilized the Model View Controller design pattern. Typically these were custom J2EE or .NET applications that were modelled after the J2EE blueprint DP library. More often than not we used a package that was built internally that could plug and play with any new implementation. It worked well, the system was very stable with few to no bugs and could be used by any level of developer.

However for each unique environment or company you will need to build your own generic MVC package and that takes time and more importantly it takes buy-in from a business sponsor who could care less if you utilize MVC, XYZ or any other acronym'd flavor of the month. Even if you do get buy in, you need a commitment from internal IT leadership to ensure that all developers are in tune with the mindset required to work in a model first environment.

When Microsoft first came out with their own flavor of MVC in late 2007 I was hopeful that it would provide the standard plumbing that could reduce the overhead required for a new environment. For the most part, it did that. Yes, it was very rudimentary and was limited the amount of control you had in the separation of concerns, but it gave Microsoft Developers a good entry into the MVC world. In the past true MVC frameworks were mostly in the J2EE domain. I also came to respect the simplicity of the MS version since that should be what we strive for as developers.

The one thing that the MS MVC package is missing is proper flow control. Really the only thing within the MS model for flow control is URL mapping. I was able to speak with Scott Guthrie a few years back at a VS Live event and we spoke in great detail about this missing piece of the puzzle. He did say that it was a point of contention/discussion within the MS development team but that they ultimately chose the URL mapping model to KISS, which is again not always a bad thing. About a year after that discussion and after trying to integrate MS MVC maps into a service environment you quickly find that it is difficult if not impossible to easily take that step. The missing component is flow control.

Most SOA implementations involve heavy use of workflow and URL mapping does not integrate easily with this model. I recently gave a webinar on how to implement flow control within your MS MVC applications. I patterned my discussion (note the pun) after the Finite State Machine design pattern which basically gives every data movement a required start sate, possibly a bunch of processes against that data, and a definite end state. This meshes perfectly with the process flows that are so integral to your SOA implementation.

Adding better flow control to your MS MVC application also is crucial in allowing you to bring the business into your design discussions since the core of your state machine is based on workflow models, something business owners understand well.