Is MVC really a advantageus move forward

Right now there are a whole lot of ASP.NET web forms coders out there who confess that they simply don't comprehend ASP.NET MVC. In a lot of ways, I can associate with them. The vocal fraction that speaks about ASP.NET MVC talk about it with such zeal that they make it seem like you'd have to be a fool not to change over. In actuality, the verdict isn't nearly as straightforward.

ASP.NET web forms aren't going anyplace. These techniques have their right place in a web developer's toolbox and it's critical to identify their benefits and weaknesses. In general, the ASP.NET MVC framework is inclined to compromise ease-of-use (e.g. viewstate, validation, etc.) in order to give developers stronger control over the reins. This can be a terrific thing, but only if you take advantage of it. Otherwise it can just as easily be a issue.

With all of this, I have established a easy metric to ascertain if ASP.NET MVC is appropriate for you. The way I see it, there are three or more primary reasons a developer should decide on the ASP.NET MVC framework over ASP.NET web forms. If none of these reasons are compelling to you, then you need to stick with ASP.NET web forms:

To Increase Control and Extensibility

As pointed out in the comments, ASP.NET MVC provides you much more management and extensibility options than ASP.NET web forms. You get entire control over the webpage request lifecycle and the potential to exchange out several key parts 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 acquire 100 % management over the rendered HTML. In general, the rendered HTML from ASP.NET web forms applications is atrocious. The web controls it employs build garbage ids and disguised . fields galore that not only impede 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 datagrids or repeaters that amazingly create markup for you. There aren't any invisible fields to continue to persist state for you. It's just you, the HTML, and a handful of extension procedures.

To Unit Test

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

There's a good reason why the most significant ASP.NET MVC practitioners also have a tendency to be TDD proponents; it's simply because ASP.NET MVC essentially will allow for TDD. In my opinion, I believe this is where all the zeal comes from. Simply put: it's genuinely hard to do TDD with ASP.NET web forms and genuinely easy to do it in ASP.NET MVC.

To Have a shot at Something Different

I should mention that learning ASP.NET MVC is an unbelievably engaging process since the ASP.NET MVC framework team has been so interactive in the process. I feel a huge part of the attractiveness of ASP.NET MVC is that the community's knowledge is not only being taken into consideration, it is definitely being sought after. The framework has sparked so many posts and debates over best practices that simply following along presents you to concepts you might formerly have been unaware of. I would really propose studying the ASP.NET MVC framework for this factor alone.

So there it is. Apart from those three, I can't think of any other reasons why a developer would learn ASP.NET MVC. Perhaps this is why the adoption rate isn't nearly as high as we believe that it should be. The motivator for using the framework generally reduces down to unit testing, control/extensibility, and boredom/interest. Good reasons, but not really game breakers for the large bulk of programmers out there.