Docstoc

MVC vs Web forms

Document Sample
MVC vs Web forms Powered By Docstoc
					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
stack: JavaScript, CSS, HTML.

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
      HTML and JavaScript details.

   4) For modern Web pages, abstraction from HTML is a serious issue as it hinders
      accessibility, browser compatibility, and integration with popular JavaScript
      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.

   3) The integration of external JavaScript frameworks will be simpler and more
      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
      page.

   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
      freedom.
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-
behind classes.

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
control.

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
developer.




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,
others may see as a weakness. For example, full control over HTML, JavaScript, and
CSS, ASP.NET MVC means that you enter the Web elements manually. Much of this
pain can be mitigated, however, with some of the more recent JavaScript libraries and
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
      productivity.

   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
       detailed level.
      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
       mind.
      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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:9/7/2011
language:English
pages:5