subject:
Is Mvc Really A Good Move Forward
[print this page] There are a lot of ASP.NET web forms coders out there who acknowledge that they simply don't comprehend ASP.NET MVC. In a lot of ways, I can associate with them. The expressive community that speaks about ASP.NET MVC speak about it with such enthusiasm that they make it seem like you'd have to be a fool not to move over. In reality, the choice isn't nearly as simple.
ASP.NET web forms aren't going anyplace. These approaches have their right place in a web developer's toolbox and it's critical to identify their strengths and deficiencies. In general, the ASP.NET MVC framework tends to forfeit ease-of-use (e.g. viewstate, validation, etc.) in order to provide developers more restrictive control over the reins. This can be a wonderful thing, but only if you take advantage of it. Otherwise it can just as easily be a issue.
With all of this, I have created a easy metric to find out if ASP.NET MVC is right for you. The way I see it, there are about three primary factors a developer should select the ASP.NET MVC framework over ASP.NET web forms. If none of these causes are persuasive to you, then you will need to stick with ASP.NET web forms:
To Increase Control and Extensibility
As pointed out in the remarks, ASP.NET MVC allows you more management and extensibility options than ASP.NET web forms. You get entire management over the web page request lifecycle and the potential to substitute out several key items of the framework (e.g. view engine, routing, etc.), none of which is attainable with ASP.NET web forms.
In addition to this, you also get full control over the delivered HTML. In general, the rendered HTML from ASP.NET web forms apps is terrible. The web controls it utilizes create garbage ids and hidden fields in abundance that not only hinder the overall performance of a site, but also make CSS styling and Javascript development a pain. ASP.NET MVC makes you to be more in tune with your HTML. There aren't any datagrids or repeaters that like magic , create markup for you. There aren't any disguised . fields to persist state for you. It's just you, the HTML, and a number of extension methods.
To Unit Test
This, in my viewpoint, is the most engaging rationale to use ASP.NET MVC. When it comes to unit testing, ASP.NET MVC simply beats ASP.NET web forms. It's not even close. Whereas ASP.NET web forms requires you to hop through all forms of hoops to test around the page event lifecycle, the ASP.NET MVC framework virtually begs to be tested. There are interfaces almost everywhere proclaiming "mock me up!".
There's a good reason why the biggest ASP.NET MVC enthusiasts also tend to be TDD supporters; it's because ASP.NET MVC really will allow for TDD. Personally, I think this is where all the enthusiasm comes from. Basically put: it's really hard to do TDD with ASP.NET web forms and extremely straightforward to do it in ASP.NET MVC.
To Try out Something Different
I should mention that studying ASP.NET MVC is an unbelievably engaging process since the ASP.NET MVC framework team has been so interactive in the process. I believe a large part of the charm 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 started so many discussions and discussions over best practices that merely following along introduces you to ideas you might previously have been uninformed of. I would really advise figuring out the ASP.NET MVC framework for this purpose alone.
So there it is. Aside from those three, I can't think of any other reasons why a programmer would learn about ASP.NET MVC. Perhaps this is why the adoption rate isn't nearly as high as we believe it should be. The incentive for using the framework fundamentally comes down to unit testing, control/extensibility, and feeling of boredom/interest. Fine reasons, but not really game breakers for the vast majority of programmers out there.
