It is very common to hear developers talk about successfully switching to MVC and generating much cleaner applications and there is no doubt that using MVC can certainly generate that.  But as with any technology/framework, misusing it can still result in an application with maintainability issues and the need for the developer to make undesirable decisions.

Such was the case out here in New York where our client had decided to use the MVC framework with the Coolite UI toolset. I am a big believer then when it comes to using the MVC framework one needs to be careful that the toolset you are using also leverages what MVC gives you.  In the case of the project out here, after numerous discussions it was clear that really the way we were approaching the project we were just not going to leverage MVC in a way that would make sense to use it.  In reality, the project would be better off, given the aims, as a Silverlight project, but due to circumstances surrounding the project it was not an option.

In addition, we had decided to use the Coolite control toolkit for UI.  Given the way that Coolite is setup it makes sense to use it with WebForms over MVC.  While you can certainly use MVC with Coolite (as demonstrated by http://mvc.coolite.com) after spending a week developing in MVC with Coolite it became apparent that it didn’t make sense and I felt we were heading for some problems.  I took these problems to the other developers and after some conversation we decided we needed to talk to the client about possibly changing, let me enumerate some of the arguments that were made:

• MVC’s biggest strength is the decoupling of the view from the controller and the lack of reliance on server controls
• In our case we are not really using this methodology heavily, instead relying more on web services to talk to the database. This due to the other devices that must be able to tie into this system
• Coolite is designed to work with ASP .NET webforms.  Using Coolite with MVC means a large reliance on JavaScript to gather values and perform saves.
• Using Webforms we can use the code behind to leverage .NET in a way that makes sense given the operations we are performing
• With Webforms we can still use web service method calls to get data from our database.  It also allows use to make WCF calls via code-behind if needed

The big point that was made here was that we are only talking minimal gain using MVC from a structure standpoint vs. potentially difficult choices in saving and persisting data and leaning very heavily on JavaScript.  In addition, if done properly an ASP .NET Webform app can be just as well organized as an MVC application if done correctly.  I have certainly see it done by some of the best in the industry and I have their experience to lean on in doing this.  I really think this is the best decision, as much as I want to use MVC, I think you just don’t gain anything give what we are doing and how we are approaching it.