This article is currently in the process of being translated into Portuguese (~5% done).
If you are fluent in Portuguese, then please help us - just point to any untranslated element (highlighted with a yellow left border - remember that images should have their titles translated as well!) inside the article and click the translation button to get started. Or have a look at the current translation status for the Portuguese language.
If you see a translation that you think looks wrong, then please consult the original article to make sure and then use the vote button to let us know about it.
Please help us by translating the following metadata for the article/chapter, if they are not already translated.
If you are not satisfied with the translation of a specific metadata item, you may vote it down - when it reaches a certain negative threshold, it will be removed. Please only submit an altered translation of a metadata item if you have good reasons to do so!
ASP.NET MVC vs. Web Forms
A primeira versão do ASP.NET foi lançada em 2002, tendo como única opção Web Forms view engine. Porem mais tarde, para apoiar MVC, a Microsoft estendeu ASP.NET para suportar múltiplas view engines. Mas durante muitos anos, ao usar ASP.NET, Web Forms estariam a ser usadas automaticamente.
Microsoft had a very commendable goal when they created Web Forms: They wanted to abstract as much of the gritty details of the HTTP protocol and the stateless nature of it away and make web development feel much more like developing a Windows application, which was already a pretty pleasant experience at the time.
They did so by introducing the ViewState, which would make sure that the current state of any form was preserved during post backs to the server and they did it with server controls, which encapsulated the rendering of HTML and CSS into an arbitrary control which you could customize using logical properties instead of being forced to mix HTML and CSS directly.
They also introduced the event driven model, already known to the Windows developers at that time, to allow the developer to respond to actual events, like a button being clicked or a checkbox being changed, instead of doing manual checks for this each time the page was loaded. This also meant that markup and code was separated, which in theory is a great thing.
Where Web Forms Failed
Web Forms was a fresh breath of air for many developers, and it likely also helped a lot of new developers, or developers only familiar with Windows application development, to learn building applications for the web. Unfortunately Microsoft didn't succeed in creating the perfect and flawless abstraction, because a number of problems quickly emerged. Some of them were fixed in later releases, while others were more fundamental to the way WebForms worked and therefore harder to change. The Web Forms technology has been criticized mainly for the following things:
ViewState makes pages heavier
By keeping track of every server control on the page in a ViewState string, which is sent back and forth between the server on each request, Web Forms pages got quite a bit heavier. If you were building a medium complex page, the resulting ViewState string could lead to an increase of several hundreds of kilobytes. This could lead to longer load times, especially on a mobile connection and with the increase of traffic from smartphones all over the world, this became a very real problem.
Server controls limits your control over HTML output
Server controls makes it easy for you to quickly create something useful, but you never get full control of the HTML which it renders. This can become a problem when you need to fine-tune your work as well as if you experience browser compatibility problems.
Web Forms is bad for automated testing
The Web Forms model was introduced before automated/unit testing became a big thing and when it did, it was easy to see that Web Forms was hard, if not impossible, to effectively unit test.
Where ASP.NET MVC is an improvement over Web Forms
ASP.NET MVC removes a lot of the abstractions implemented by Web Forms. For instance, you usually generate all of the HTML yourself, instead of relying on server controls. There is also no longer any ViewState maintained for you, effectively eliminating that problem (but also rendering several of the server controls, like the GridView and the Repeater, useless at the same time).
The MVC model is perfect for automated/unit testing, because of the loose coupling between the different layers.
Which technology should you choose?
It's important to state that while Web Forms may seem like an outdated technology when reading the above, it's actually not at all - Web Forms is still being actively developed by Microsoft and is still a possible choice when entering the world of web development with ASP.NET. Web Forms is especially well suited for situations where you want something up and running in a hurry - the big amount of advanced server controls makes it easy to accomplish something very useful in a rush, at the price of the flexibility it gives you to write all the markup manually.
If you already know how to use Web Forms, you should definitely give ASP.NET MVC a try, especially if some of the above mentioned problems have been bugging you as well. If you're new to web development, and you need to decide between the two technologies, I would still recommend giving ASP.NET MVC a try. The MVC model can seem a bit restrictive to some people, and having to follow a pattern is obviously harder in the beginning than not following one, but once you get used to it, it's very pleasant to work with and judging from the amount of attention that the MVC model receives in general, it's not likely to disappear anytime soon.
So, while ASP.NET Web Forms might be a bit easier to get started with, you should probably give ASP.NET MVC a try first, if you're new to the world of web development. Don't worry, this tutorial will get you started and guide you through the process of developing your first ASP.NET MVC application.