Why MVC instead of good old ASP.NET? Still not grasping why I should go this route?

Question

I know this question has been asked before and I read all the answers but they still don\'t give me the answers I am looking for. I need something concrete. I volunteered to g

Answer 1

The following article got me started with MVC

ASP.NET web forms aren't going anywhere. As much as I love ASP.NET MVC, it is not the end-all-be-all one-size-fits-all solution to web development. Both of these approaches have their rightful place in a web developer's toolbox and it's important to recognize their strengths and weaknesses. In general, the ASP.NET MVC framework tends to sacrafice ease-of-use (e.g. viewstate, validation, etc.) in order give developers tighter control over the reins. This can be a great thing, but only if you take advantage of it. Otherwise it can just as easily be a hindrance.

With that in mind, I have developed a quick metric to determine if ASP.NET MVC is right for you. The way I see it, there are three primary reasons a developer should choose the ASP.NET MVC framework over ASP.NET web forms. If none of these reasons are compelling to you, then you should stick with ASP.NET web forms:

To Unit Test This, in my opinion, is the most compelling reason to use ASP.NET MVC. When it comes to unit testing, ASP.NET MVC simply blows ASP.NET web forms out of the water. It's not even close. Whereas ASP.NET web forms requires you to jump through all sorts of hoops to test around the page event lifecycle, the ASP.NET MVC framework practically begs to be tested. There are interfaces everywhere screaming "mock me!".

There's a reason why the biggest ASP.NET MVC supporters also tend to be TDD proponents; it's because ASP.NET MVC actually allows for TDD. Personally, I think this is where all the zeal comes from. Simply put: it's really, really hard to do TDD with ASP.NET web forms and really, really easy to do it in ASP.NET MVC.

To Gain Control and Extensibility As pointed out in the comments, ASP.NET MVC gives you more control and extensibility options than ASP.NET web forms. You get complete control over the page request lifecycle and the ability to substitute out several key pieces of the framework (e.g. view engine, routing, etc.), none of which is possible with ASP.NET web forms.

In addition to this, you also gain full control over the rendered HTML. In general, the rendered HTML from ASP.NET web forms applications is atrocious. The web controls it utilizes generate garbage ids and hidden fields galore that not only hamper the performance of a site, but also make CSS styling and Javascript development a pain. ASP.NET MVC forces you to be more in tune with your HTML. There aren't any repeaters or datagrids that magically generate markup for you. There aren't any hidden fields to persist state for you. It's just you, the HTML, and a few extension methods (which you don't even have to use).

To Learn Something New In other words, "because you feel like it". This was actually why I started using ASP.NET MVC. It never hurts to look at how you're approaching development from another angle.

I should also point out that learning ASP.NET MVC is incredibly engaging process since the ASP.NET MVC framework team has been so interactive in the process. I think a large part of the appeal of ASP.NET MVC is that the community's input is not only being taken into consideration, it is actively being sought after. The framework has sparked so many discussions and debates over best practices that simply following along introduces you to concepts you might previously have been unaware of. I would actually recommend learning the ASP.NET MVC framework for this reason alone. The threads on TDD, BDD, ORM, AJAX, etc. you stumble across during the learning process are worth it.

So there you have it. Aside from those three, I can't think of any other reasons why a developer would learn ASP.NET MVC. Maybe this is why the adoption rate isn't nearly as high as we think it should be. The incentive for using the framework essentially boils down to unit testing, control/extensibility, and boredom/curiosity. Good reasons, to be sure, but hardly game breakers for the vast majority of developers out there.