Should I MVC or Should I stay away from MVC

There are a ton of ASP.NET web forms coders out there who say that that they simply don't comprehend ASP.NET MVC. In a lot of ways, I can connect with them. The vocal community that speaks about ASP.NET MVC speak about it with such fervour that they make it sound like you'd have to be a twit not to transition over. In actuality, the choice isn't nearly as easy.

ASP.NET web forms aren't going anywhere. These strategies have their right place in a web developer's toolbox and it's crucial to discover their benefits and flaws. In general, the ASP.NET MVC framework is likely to sacrifice ease-of-use (e.g. viewstate, validation, etc.) in order to provide developers stronger control over the reins. This can be a terrific thing, but only if you take advantage of it. Or else it can just as readily be a problem.

With all of this, I have produced a quick metric to figure out if ASP.NET MVC is appropriate for you. The way I see it, there are three or more primary motives a developer should select the ASP.NET MVC framework over ASP.NET web forms. If none of these causes are compelling to you, then you should stick with ASP.NET web forms:

To Acquire Control and Extensibility

As pointed out in the comments, ASP.NET MVC supplies you much more management and extensibility options than ASP.NET web forms. You get total control over the site request lifecycle and the ability to substitute out several key sections of the framework (e.g. view engine, routing, etc.), none of which is achievable with ASP.NET web forms.

In addition to this, you also achieve full management over the rendered HTML. In general, the rendered HTML from ASP.NET web forms programs is dreadful. The web controls it uses produce trash ids and disguised . fields galore that not only limit the performance of a site, but also make CSS style and Javascript development a pain. ASP.NET MVC allows you to be much more in tune with your HTML. There aren't any datagrids or repeaters 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 handful of extension procedures.

To Unit Test

This, in my belief, is the most convincing rationale to use ASP.NET MVC. When it comes to unit testing, ASP.NET MVC easily beats ASP.NET web forms. It's not even close. Whereas ASP.NET web forms needs you to hop through all forms of hoops to test around the page event lifecycle, the ASP.NET MVC framework just about begs to be tested. There are interfaces all around you stating "mock me up!".

There's a reason why the greatest ASP.NET MVC enthusiasts also usually tend to be TDD proponents; it's simply because ASP.NET MVC in fact allows for TDD. Professionally, I believe this is where all the zeal comes from. Basically put: it's definitely hard to do TDD with ASP.NET web forms and definitely uncomplicated to do it in ASP.NET MVC.

To Attempt Something New

I should point out that understanding ASP.NET MVC is an incredibly engaging process since the ASP.NET MVC framework team has been so interactive in the process. I believe a significant part of the lure of ASP.NET MVC is that the community's insight is not only being taken into consideration, it is definitely being wanted after. The framework has started so many discussions and dialogues over best practices that simply following along presents you to aspects you might formerly have been unaware of. I would actually recommend understanding the ASP.NET MVC framework for this reason alone.

So there it is. Aside from those three, I can't think of any other reasons why a programmer would learn ASP.NET MVC. It's possible this is why the adoption rate isn't nearly as high as we think it should be. The motivation for using the framework essentially reduces down to unit testing, control/extensibility, and boredom/curiosity. Good reasons, but seldom game breakers for the large majority of developers out there.