Since Microsoft joined the MVC foray with ASP.NET MVC (other options existed previously, such as Monorail) I’ve personally witnessed (and been part of ) a lot of MVC vs. WebForms discussions. Usually these discussions end up with opposite sides taking their ball and going home in a pissed-off offended rage. Usually the WebForm fans snicker and say “Why change whats broken, I have X number of users and I make X money off of my app which has X % of uptime and it work great!”, etc etc etc. They’re right. Why change it? The MVC folks usually reply with “What about standards, ease of use, integration, ease of use with js frameworks, restful architectures, separation of concerns, SOLID, maintainability, and testability as well as a working app”? They’re also right. What about those things the MVC fans talk about? Most of those things require you jump through some hoops to do them in WebForms. Some of these problems were solved long ago by some smart WebForms people. Thats the counter argument. But then again all programming problems have a common counter argument – Hasnt everything already been solved by Lisp and Smalltalk (or so the saying goes)?
Each side of this arguments has their own opinion and their own valid points. So be it. Learn to live with it.
Personally, I’m a HUGE ASP.NET MVC advocate. However I’m realistic in my thought process and I use the right tool for the right job.
Here’s a perfect example: This last weekend I helped lead the Twin Cities GiveCamp team to a successful web project implementation for the Animal Humane Society. The solution was a web application. Almost everyone I know would say “Oh cool! You did a nice fancy MVC App right?!” Nope. Sure didnt. Myself and the team agreed that while MVC was what WE as a group wanted to do, it wasnt the right thing for the job.
We had 48 hours to create a solution for the non-profit. We needed simple app that was forms over data and we also needed to make sure that anyone who maintains this code base in the future would be able to update it. With not everyone knowing asp.net mvc we chose WebForms. Everyone on the team knew WebForms and how it worked. If we went with MVC I think the solution might have have been cleaner, but I do feel we would have NOT completed the job on time. In the end the MVC learning curve was too much for the team. Therefore in this instance, MVC was not the correct choice. We ended up using ASP.NET 3.5 WebForms, jQuery, and some other controls to get the job done. It worked out great and we’re in the process of setting the client up with a hosting account with DiscountASP.NET so they can start using the app as soon as possilbe. Choosing web forms allowed us to get the app done save their organizatoin time and money which allows them to improve treatment and facilities for the animals (which is the real end goal). If we chose MVC we most likely would not have finished and the entire event would have been a failure. No business problem solved, plain and simple.
The proof is in the pudding: Use what works best for the given problem … and really … who cares what technology you use to implement a given solution. If it doesnt work, you failed. If it works, you succeeded. This holds true if you’re using ASP.NET vs. Rails vs. PHP vs. JSP. In the end, ship working software. Otherwise, you’ve taken a long ride on the dreaded fail train.
What I’m trying to say is … do what you need to do to get the job done. Don’t be a technical-framework-nazi. If you love ASP.NET MVC, cool! If you love WebForms, cool! Get the job done, get paid, pay your bills and go home and spend time with your family.
What’s a big deal to you today, won’t be a year from now. Remember, no one ever laid down in their deathbed thinking “Ya know what, I should have used ASP.NET MVC for that one project.”