Advantages of ASP.Net Web Forms -
1) ASP.NET Web Forms is stable and mature, and it is supported by heaps of third
party controls and tools.
2) One of the keys to the rapid adoption of ASP.NET is certainly the point-and-click
metaphor taken from Windows desktop development. With Web Forms, Microsoft
basically extended the Visual Basic programming model to the Web.
3) Since the web is stateless, to simulate stateful programming over the Web,
ASP.NET Web Forms introduced features such as viewstate, postbacks, and an
overall event-driven paradigm.
For example, the developer can, say, double-click on a button to automatically
generate a stub of code that will handle the user's clicking to the server. To get started
writing an ASP.NET Web application, you just need to know the basics of .NET
development, the programming interface of some ad hoc components, like server
controls. Server controls that generate HTML programmatically, and the runtime
pipeline, contribute significantly to a fast development cycle.
5) Key features of ASP.NET Web Forms are just the componentization of some ASP
best practices. For example, postback, auto-population of input fields, authentication
and authorization before page rendering, server controls, and compilation of the page,
are not features devised and created from scratch for ASP.NET Web Forms. All of
them evolved from ASP best practices. Furthermore, ASP.NET Web Forms generally
exceeded our expectations by providing a full abstraction layer atop the whole Web
6) To write an ASP page, you did need to know quite a bit about the Web and script
languages. To write an ASP.NET page, in contrast, you need to know primarily about
.NET and its compiled languages. Productivity and rapid development of data-driven,
line-of-business applications have been the selling points of ASP.NET Web Forms.
Drawbacks of Web Forms –
1) Years of experience prove beyond any reasonable doubt that separation of
concerns (SoC) has not been a natural fit with the Web Forms paradigm.
2) Automated testing of an ASP.NET Web Forms application is hard, and not
just because of a lack of SoC. ASP.NET Web Forms is based on a monolithic
runtime environment that can be extended, to some extent, but it is not a
pluggable and flexible system. It's nearly impossible to test an ASP.NET
application without spinning up the whole runtime.
3) To achieve statefulness, the last known state of each server page is stored
within the client page as a hidden field—the viewstate. Though viewstate has
too often been held up as an example of what's wrong with Web Forms, it is
not the monster it's made out to be. In fact, using a viewstate-like structure in
classic ASP was a cutting-edge solution. From an ASP perspective, simulation
of statefulness (that is, postback, viewstate, controls) was a great achievement,
and the same was also said at first about how Web Forms isolated itself from
4) For modern Web pages, abstraction from HTML is a serious issue as it hinders
frameworks like jQuery, Dojo, and PrototypeJS. The postback model that
defaults each page to post to itself, makes it harder for search engines to rank
ASP.NET pages high. Search engines and spiders work better with links with
parameters, better if rationalized to human-readable strings. The postback
model goes in the opposite direction. Also, an excessively large viewstate is
problematic because the keyword the rank is based on may be located past the
viewstate, and therefore far from the top of the document. Some engines
recognize a lower rank in this case.
Benefits of ASP.NET MVC –
1) You can disable or control the size of the viewstate. (Even though very few
developers seem to have noticed, the size of the viewstate decreased
significantly in the transition from ASP.NET 1.1 to ASP.NET 2.0 when
Microsoft introduced a much more efficient serialization algorithm. In
ASP.NET 4.0, you should also expect improvements in the way in which
viewstate can be disabled and controlled.)
2) You can use an ad hoc HTTP module to do URL rewriting or, better yet, you
can use the newest Web routing API from ASP.NET 3.5 SP1. In ASP.NET
4.0, you can minutely control the ID of elements, including scoped elements.
effective. Finally, the history management API in ASP.NET 3.5 SP1 made
AJAX and post-back work together while producing a search-engine-friendly
4) When you write an ASP.NET MVC application, you think in terms of
controllers and views. You make your decisions about how to pass data to the
view and how to expose your middle tier to the controllers. The controller
chooses which view to display based on the requested URL and pertinent data.
Each request is resolved by invoking a method on a controller class.
5) No postbacks are ever required to service a user request. No viewstate is ever
required to persist the state of the page. No arrays of black-box server controls
exist to produce the HTML for the browser.
6) With ASP.NET MVC, you rediscover the good old taste of the Web—stateless
behavior, full control over every single bit of HTML, total script and CSS
The HTML served to the browser is generated by a separate, and replaceable, engine.
There's no dependency on ASPX physical server files. ASPX files may still be part of
your project, but they now serve as plain HTML templates, along with their code-
The default view engine is based on the Web Forms rendering engine, but you can use
other pluggable engines such as nVelocity or XSLT. (For more details, have a look at
the MVCContrib Web site at mvccontrib.codeplex.com.)
The runtime environment is largely the same as in ASP.NET Web Forms, but the
request cycle is simpler and more direct.
An essential part of the Web Forms model, the page lifecycle, is no longer necessary
in ASP.NET MVC. It should be noted, though, that the default view engine in
ASP.NET MVC is still based on the Web Forms rendering engine. This is the trick
that allows you to use master pages and some server controls in ASP.NET MVC
views. As long as the view engine is based on Web Forms, the view is an ASPX file
with a regular code-behind class where you can handle classic events such as Init,
Load, PreRender, plus control-specific events such as RowDataBound for a GridView
If you switch off the default view engine, you no longer need Page_Loader other
events of the standard page lifecycle. Figure 1 compares the run-time stack for Web
Forms and ASP.NET MVC.
It should be noted that the "Page lifecycle" boxes in Figure 1 have been collapsed for
readability and include several additional events each. Anyway, the run-time stack of
ASP.NET MVC is simpler and the difference is due to the lack of a page lifecycle.
However, this makes it problematic to maintain the state of visual elements across
page requests. State can be stored into Session or Cache, but this decision is left to the
The MVC acronym stands for Model-View-Controller. However, you should note that
the pattern depicted in Figure 2 doesn't exactly match the classic formulation of the
MVC pattern. In particular, in the original MVC paper, Model and View are tied
together through an Observer relationship. The MVC pattern, though, is deliberately
loosely defined and, even more importantly, was devised when the Web was still to
come. Adapting MVC to the Web moved it toward the model in Figure 2, which is
also known as Model2. In general, when you talk or read about MVC be aware that
there are quite a few slightly different flavors of it within the literature.
Drawbacks of ASP.NET MVC
So ASP.NET MVC brings to the table a clean design with a neat separation of
concerns, a leaner run-time stack, full control over HTML, an unparalleled level of
extensibility, and a working environment that enables, not penalizes, test-driven
development (TDD). Is ASP.NET MVC, therefore, a paradise for Web developers?
Just like with Web Forms, what some perceive as a clear strength of ASP.NET MVC,
CSS, ASP.NET MVC means that you enter the Web elements manually. Much of this
even different view engine.
1) In general, though, there's no sort of component model to help you with the
generation of HTML, as there is in the Web Forms approach. Currently,
HTML helpers and user controls are the only tools you can leverage to write
HTML more quickly. As a result, some ASP.NET developers may see
ASP.NET MVC as taking a step backward in terms of usability and
2) Another point to be made, regarding the impact of ASP.NET MVC on
everyday development, is that it requires some upfront familiarity with the
MVC pattern. You need to know how controllers and views work together in
the ASP.NET implementation. In other words, ASP.NET MVC is not
something you can easily learn by experimenting. In my experience, this may
be the source of decreased productivity for the average Web Forms developer.
Undisputable Facts -
ASP.NET Web Forms and ASP.NET MVC are not competitors in the sense that one
is supposed to replace the other. You have to choose one, but different applications
may force you to make different choices. In the end, it's really like choosing between
a car and a motorcycle when making a trip. Each trip requires a choice, and having
both vehicles available should be seen as an opportunity, not as a curse. Here are
some facts about the frameworks:
Web Forms is hard to test.
ASP.NET MVC requires you to manage the generation of HTML at a more
ASP.NET MVC is not the only way to get SoC in ASP.NET.
Web Forms allows you to learn as you go.
View state can be controlled or disabled.
Web Forms was designed to abstract the Web machinery.
ASP.NET MVC exposes Web architecture.
ASP.NET MVC was designed with testability and Dependency Injection in
ASP.NET MVC takes you towards a better design of the code.
ASP.NET MVC is young and lacks a component model.
ASP.NET MVC is not anti-Web Forms.
ASP.NET MVC was not created to replace Web Forms but to partner it. ASP.NET
MVC turns some of the weaker elements of Web Forms into its own internal
strengths. However, problems such as lack of testability, SoC, SEO, and HTML
control can be avoided or reduced in Web Forms with some discipline and good
design, though the framework itself doesn't provide enough guidance.