La información aquí ofrecida es contenido traducido automáticamente que los miembros de la comunidad pueden editar. Quienes deseen contribuir a mejorar la traducción, pueden hacer clic en el vínculo “editar” asociado a cualquiera de los siguientes enunciados.
Cutting Edge
Comparing Web Forms And ASP.NET MVC
Dino Esposito
Contents
I first saw Microsoft ASP.NET in action in 1999, when it was tentatively named ASP+.
At that time, building a Web application on the Microsoft platform was a matter of assembling a bunch of Active Server Pages (ASP).
In a typical ASP page, you find HTML literals interspersed with code blocks.
In code blocks, script code (mostly VBScript) is used to incorporate data generated by COM objects, such as components from the ActiveX Data Objects (ADO) framework.
Undoubtedly, the introduction of ASP.NET in the late 1990s was a big step forward, as it represented a smart way to automate the production of HTML displayed in a client's browser.
ASP.NET simplified a number of everyday tasks and, more importantly, enabled developers to work at a higher level of abstraction.This allowed them to focus more on the core functions of the Web application rather than on common tasks around Web page design.
Based on server controls, ASP.NET allows developers to build real-world Web sites and applications with minimal HTML and JavaScript skills.
The whole point of ASP.NET is productivity, achieved through powerful tools integrated in the runtime as well as the provision of development facilities, such as server controls, user controls, postback events, viewstate, forms authentication, and intrinsic objects.
The model behind ASP.NET is called Web Forms and it was clearly inspired by the desktop Windows Forms model (in turn deeply inspired by the Visual Basic Rapid Application Development philosophy).
So why did Microsoft release "another" ASP.NET framework, called ASP.NET MVC?
In this article, I'll explore the pros and cons of both ASP.NET Web Forms and ASP.NET MVC.
Benefits of ASP.NET Web Forms
As noted, ASP.NET Web Forms is stable and mature, and it is supported by heaps of third party controls and tools.
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.
Desktop development, however, is stateful whereas the Web is inherently stateless.
So the Web Forms model essentially abstracted a number of features to provide a simulated stateful model for Web developers.
As a result, you didn't have to be a Web expert with a lot of HTML and JavaScript knowledgeto write effective Web applications.
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.
At the end of the day, 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.
Ten years ago, ASP developers (including myself) were looking for exactly the set of features that Web Forms ended up providing.
Furthermore, ASP.NET Web Forms generally exceeded our expectations by providing a full abstraction layer atop the whole Web stack: JavaScript, CSS, HTML.
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.
Until now, that is.
Drawbacks of Web Forms
Like many other things in this imperfect world, ASP.NET Web Forms is not free of issues.
Years of experience prove beyond any reasonable doubt that separation of concerns (SoC) has not been a natural fit with the Web Forms paradigm.
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.
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.
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
Some of the recognized issues with the Web Forms model can be fixed within ASP.NET 4.0.
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.) 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.
Likewise, in ASP.NET 4.0 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 postback work together while producing a search-engine-friendly page.
In many aspects, the Web Forms model in ASP.NET 4.0 is a better environment that tackles some of the aforementioned flaws.
So what's the point of ASP.NET MVC?
You'll find a good introduction to ASP.NET MVC in the March 2008 issue
MSDN Magazine
("
Building Web Apps without Web Forms
"), where Chris Tavares explains the basics of ASP.NET development without Web Forms.
In summary, ASP.NET MVC is a completely new framework for building ASP.NET applications, designed from the ground up with SoC and testability in mind.
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.
No postbacks are ever required to service a user request.
No viewstate is ever required to persist the state of the page.
No arraysof black-box server controls exist to produce the HTML for the browser.
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_Loador other events of the standard page lifecycle.
Figure 1 compares the run-time stack for Web Forms and ASP.NET MVC.
.gif)
Figure 1 The Run-Time Stack at a Glance (Click the image for a larger view)
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.
Figure 2
illustrates the sequence of an ASP.NET MVC request.
.gif)
Figure 2 The Sequence Diagram of an ASP.NET MVC Request (Click the image for a larger view)
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.
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.
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.
The Right Perspective
As an architect or developer, it is essential that you understand the structural differences between the frameworks so that you can make a thoughtful decision.
All in all, ASP.NET Web Forms and ASP.NET MVC are functionally equivalent in the sense that a skilled team can successfully use either to build any Web solution.
The skills, education, and attitude of the team, though, are the key points to bear in mind.
As you may have figured out yourself, most of the features presented as a plus for either framework may also be seen as a minus, and vice versa.
Full control over HTML, for example, may be a lifesaver to one person but a nightmare to another.
Personally, I was shocked the first time I saw the content of a nontrivial view page in ASP.NET MVC.
But when I showed the same page to a customer whose application was still using a significant number of ASP pages, well, he was relieved.
If you have accessibility as a strict requirement, you probably want to take full control over the HTML being displayed.
And this is not entirely possible with Web Forms.
On the other hand, if you're building a heavy data-driven application, you'll welcome the set of data-bound controls and statefulness offered by Web Forms.
Correctly, Microsoft has not positioned ASP.NET MVC as a replacement for ASP.NET Web Forms.
Web Forms is definitely a pattern that works for Web applications.
At the same time, Ruby-on-Rails has proved that MVC can also be a successful pattern for Web applications; and ASP.NET MVC confirms this.
In the end, Web Forms and ASP.NET MVC have pros, cons, and structural differences that affect various levels.
Generalizing, I'd say that Web Forms embraces the RAD philosophy whereas ASP.NET MVC is TDD-oriented.
Further, Web Forms goes toward an abstraction of the Web that simulates a stateful environment, while ASP.NET MVC leverages the natural statelessness of the Web and guides you towards building applications that are loosely coupled and inherently testable, search-engine friendly, and with full control of HTML.
What's the Perfect Model for ASP.NET?
After using Web Forms for years, I recognize a number of its drawbacks, and ASP.NET MVC addresses them quite well: testability, HTML control, and separation of concerns.
But though I see ASP.NET MVC as an equally valid option at this time, I don't believe it to be the silver bullet for every Web application.
In my opinion, ASP.NET MVC today lacks some level of abstraction for creating standard pieces of HTML.
HTML helpers are just an interesting attempt to speed up HTML creation.
I hope to see in the near future a new generation of MVC-specific server controls, as easy and quick to learn and use as Web Forms server controls, but totally unbound from the postback and viewstate model.
My hopes are for a System.Web.Mvc.GridView control that saves me from writing a loop to generate an HTML table, while offering column templates, server-side data-binding events, and styling options.
What would be the difference between such an MVC GridView and today's Web Forms GridView?
The MVC GridView would only emit HTML plus, optionally, some row-specific JavaScript, but it wouldn't manage things like paging and sorting.
Paging and sorting will be delegated to other specific controls or plain links created by the developer.
In this way, the MVC GridView could bring some RAD flavor to ASP.NET MVC, speeding up the development of pages without precluding handcrafted pages.
Going back to the root of the problem, the key difference between Web Forms and ASP.NET MVC is the underlying pattern.
Web Forms is a model based on the "Page Controller" pattern.
Web Forms are UI-focused and centered around the concept of a page: the page gets input, posts back, and determines the output for the browser.
The development environment was therefore devised to enable rapid prototyping, via wizards and rich designers.
Any user action ends up in a method on the code-behind class of each page.
At that point, though, nothing prevents you from using proper SoC and nothing really stops architects from imposing patterns like MVC, Model-View-Presenter (MVP) or even Model-View-View-Model (MVVM).
The Web Forms architecture does not encourage SoC, but it doesn't prevent it either.
The Web Forms architecture makes it seductive to opt for drag-and-drop of controls, to code logic right in event stubs without further separation, and to drop data sources right on the page, which couples the UI directly to the database.
MVC is neither prohibited nor a blasphemy in Web Forms; it's just that very few developers practice it because it requires working around much of the Web Forms infrastructure.
Testability is a different story.
ASP.NET Web Forms doesn't prevent unit testing, but it requires much disciple and repetitive boilerplate coding to do so.As long as you code your way to SoC you can test and reuse presentation and business logic.
Sure, you likely don't have the Visual Studio project template to create a test project for you.
You need to become familiar with testing and mocking frameworks and manage those projects yourself.
But this can be done.
From a testability perspective, though, a real difference exists between Web Forms and ASP.NET MVC.
In Web Forms, you just don't have the flexibility of ASP.NET MVC.
This is a true limitation.
ASP.NET MVC is designed with testability in mind,which means that the framework architecture guides the developer to write code that is inherently testable, that is isolated from the context or connected to it via contracted interfaces.
Even more importantly, in ASP.NET MVC intrinsic objects are mockable as they expose interface and base classes.
From a testing standpoint, the best you can do in Web Forms is to move your logic into separate and easily testable classes.
Then, you test the presentation (ASPX and code-behind) by sending HTTP requests and checking the results.
You can't do this in Web Forms without spinning up the whole ASP.NET runtime, however.
In ASP.NET MVC, the majority of testing is to assure that the data being passed into the view is correct.
In addition, you can mock up intrinsic objects and run your tests in a genuinely isolated environment.
We should also note that control over HTML and SEO-friendly URLs, both advantages of ASP.NET MVC, can be achieved to some extent in Web Forms.
ASP.NET 3.5 SP1, in particular, includes the URL Routing and History API for SEO.
CSS adapters, instead, are the tools to leverage to try to control HTML in Web Forms.
Integration with JavaScript and AJAX frameworks is, frankly, no longer an issue in Web Forms.
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.
-
Viewstate 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.
At the End of the Day
We have seen that there are pros and cons in both Web Forms and ASP.NET MVC.
Many developers, however, seem to favor ASP.NET MVC because it represents the only way to get SoC and testability into their applications.
Is it really the only way?
No.
However, ASP.NET MVC makes it easier and natural to achieve SoC and write more testable code.
ASP.NET MVC doesn't magically transform every developer into an expert architect and doesn't prevent developers from writing bloated and poorly designed code.
At the end of the day, both Web Forms and ASP.NET MVC help to build applications that are designed and implemented to deal effectively with the complexity of real-world solutions.
No software magic exists, and none is yet supported by the ASP.NET platform.
Dino Esposito is an architect at IDesign and the co-author of Microsoft .NET: Architecting Applications for the Enterprise (Microsoft Press, 2008).
Based in Italy, Dino is a frequent speaker at industry events worldwide.
You can join his blog at
weblogs.asp.
net/despos
.
|
Cutting Edge
Comparación de formularios Web Forms Y ASP.NET MVC
Dino Esposito
Contenido
Vi primero Microsoft ASP.NET en acción en 1999, cuando se ha denominado provisionalmente ASP+.
En ese momento, crear una aplicación Web en la plataforma de Microsoft era una cuestión de ensamblar un montón de páginas Active Server (ASP).
En una página ASP típica, encontrará literales HTML intercalados con bloques de código.
En bloques de código, código de secuencia de comandos (principalmente VBScript) se utiliza para incorporar datos generados por los objetos COM, como los componentes desde el marco de ActiveX Data Objects (ADO).
Sin duda, la introducción de ASP.NET en la década fue un gran paso hacia adelante y lo representados de forma inteligente para automatizar la producción de HTML que se muestran en explorador del cliente.
ASP.NET simplifica diversas tareas diarias y, lo que es más importante, habilitados a los programadores trabajan en un nivel mayor de abstraction.This permiten puedan centrarse más en las funciones principales de la aplicación Web que en las tareas comunes alrededor de diseño de la página Web.
Basada en controles de servidor, ASP.NET permite a los programadores generar sitios Web y aplicaciones con conocimientos HTML y JavaScript mínima de mundo real.
El punto de ASP.NET todo es productividad, consigue eficaces herramientas integradas en el motor en tiempo de ejecución, así como la provisión de servicios de desarrollo, como controles de servidor, controles de usuario, los eventos de devolución de datos, viewstate, autenticación de formularios y objetos intrínsecos.
El modelo de ASP.NET se denomina formularios Web Forms y claramente se inspiró por el modelo escritorio de Windows Forms (en vez profundamente inspirado por la filosofía de desarrollo rápido de aplicaciones Visual Basic).
Por lo tanto, ¿por qué Microsoft versión "otro" marco ASP.NET, denominado ASP.NET MVC?
En este artículo, explicaré los pros y contras de formularios Web Forms de ASP.NET y ASP.NET MVC.
Ventajas de formularios Web Forms ASP.NET
Como se indicó, formularios Web Forms de ASP.NET es estable y para adultos y es compatible con montones de los controles de terceros y las herramientas.
Una de las claves para la rápida adopción de ASP.NET es ciertamente la metáfora de señalar y hacer clic tomada de desarrollo de escritorio de Windows.
Con formularios Web Forms, Microsoft básicamente ampliado el modelo de programación de Visual Basic en el Web.
Desarrollo de escritorio, sin embargo, es con estado, mientras que el Web es, inherentemente sin estado.
Por lo tanto, el modelo de formularios Web Forms abstrae esencialmente una serie de características para proporcionar un modelo de estado simulado para desarrolladores.
En consecuencia, no tiene que ser un experto de Web con una gran cantidad de HTML y JavaScript knowledgeto escribir aplicaciones Web eficaces.
Para simular la programación con estado a través del Web, características de formularios Web Forms ASP.NET introducidas como viewstate, devoluciones de datos y un ejemplo general paradigm.For controlada por eventos, el desarrollador puede, haga doble clic por ejemplo, en un botón para generar automáticamente un código auxiliar del código que controlará el usuario hace clic para el servidor.
Para empezar a escribir una aplicación Web ASP.NET, sólo necesita conocer los fundamentos de desarrollo. NET, la interfaz de programación de algunos componentes de ad hoc, como controles de servidor.
Controles de servidor que generan HTML mediante programación y la canalización de tiempo de ejecución, contribuyen significativamente a un ciclo de desarrollo rápido.
Al final del día, características clave de formularios Web Forms de ASP.NET son la Segregación de componentes de algunas prácticas recomendadas de ASP.
Por ejemplo, devolución, automática de llenado de los campos de entrada, autenticación y autorización antes de procesamiento de páginas, controles de servidor y compilación de la página no son características idear y creado desde cero para los formularios Web Forms de ASP.NET.
Todos ellos evolucionado desde las prácticas recomendadas ASP.
Diez años, los programadores ASP (incluido yo mismo) buscaba exactamente el conjunto de características de formularios Web Forms terminaba proporcionar.
Además, ASP.NET Web Forms generalmente superado nuestras expectativas proporcionando una capa de abstracción completa parte superior de la pila de Web toda: JavaScript, CSS, HTML.
Para escribir una página ASP, necesitara saber bastante acerca de los idiomas de Web y secuencias de comandos.
Para escribir una página ASP.NET, en cambio, es necesario saber principalmente acerca de .NET y sus lenguajes compilados.
Productividad y desarrollo rápido de aplicaciones controladas por datos, la línea de negocio han sido los puntos de venta de formularios Web Forms ASP.NET.
Hasta ahora, es.
Inconvenientes de formularios Web Forms
Como muchas otras cosas en este mundo imperfecta, formularios Web Forms de ASP.NET no está libre de problemas.
Años de experiencia resultar más allá de cualquier duda razonable que separación de preocupaciones (SoC) no ha sido un ajuste natural con el paradigma de formularios Web Forms.
Pruebas automatizadas de una aplicación de formularios Web Forms ASP.NET es el disco duro y no sólo debido a una falta de SoC. de
Web de ASP.NET se basa en un entorno en tiempo de ejecución monolítico, que se puede extender en cierta medida, pero no es un sistema flexible y conectable.
Es casi imposible probar una aplicación de ASP.NET sin girando hasta el tiempo de ejecución todo.
Para lograr statefulness, el último estado conocido de cada página de servidor se almacena en la página de cliente como un campo oculto, el estado de vista.
Aunque viewstate demasiado a menudo se ha suspendido como un ejemplo de problema con formularios Web Forms, no es el monster que es realizado que.
De hecho, mediante una estructura de viewstate en ASP clásico era una solución de vanguardia.
Desde una perspectiva ASP, simulación de statefulness (es decir, devolución, viewstate, controles) era un gran logro y también el mismo se dijo en primer lugar acerca de cómo formularios Web Forms había aislado propio de detalles HTML y JavaScript.
Para páginas Web modernas, abstracción de HTML es un problema grave, como obstaculiza accesibilidad, compatibilidad de explorador e integración con marcos de JavaScript populares como jQuery, Dojo y PrototypeJS.
El modelo de devolución de datos predeterminado de cada página para enviar a sí misma, dificulta que los motores de búsqueda a clasificar las páginas ASP.NET altas.
Los motores de búsqueda y arañas funcionan mejor con vínculos con parámetros, mejor si se hayan racionalizado cadenas legibles.
El modelo de devolución de datos se realiza en la dirección opuesta.
Además, un viewstate excesivamente grande es problemático porque la palabra clave se basa el rango puede encuentra más allá de viewstate y far, por lo tanto, desde la parte superior del documento.
Algunos motores de reconocen un rango inferior en este caso.
Ventajas de ASP.NET MVC
Algunos de los problemas reconocidos con el modelo de formularios Web Forms pueden corregirse dentro de ASP.NET 4.0.
Puede deshabilitar o controlar el tamaño de viewstate.
(Aunque muy pocos desarrolladores parecen que haya observado, el tamaño de viewstate disminuye considerablemente en la transición desde ASP.NET 1.1 a ASP.NET 2.0 cuando Microsoft presentó un algoritmo de serialización mucho más eficaz.
En ASP.NET 4.0, debe también esperar mejoras de la manera en que se puede deshabilitado viewstate y controlar.) Puede utilizar un módulo HTTP ad hoc para realizar la reescritura de direcciones URL o, mejor aún, puede utilizar el Web más reciente enrutamiento API de ASP.NET 3.5 SP1.
En ASP.NET 4.0, puede controlar detalladamente el identificador de elementos, incluidos los elementos con ámbito.
Asimismo, en ASP.NET 4.0 la integración de marcos externos de JavaScript será más sencillo y más eficaz.
Por último, la API de administración de historial en ASP.NET 3.5 SP1 realiza AJAX y trabajo devolución juntos al generar una página descriptivas del motor de búsqueda.
En muchos aspectos, el modelo de formularios Web Forms de ASP.NET 4.0 es un entorno mejor que trata algunos de los errores mencionados anteriormente.
¿Cuál es el punto de ASP.NET MVC?
Encontrará una buena introducción a ASP.NET MVC en el problema de marzo de 2008
MSDN Magazine
("
Creación de aplicaciones sin formularios Web Forms Web
"), donde en que Chris Tavares explica los conceptos básicos del desarrollo de ASP.NET sin formularios Web Forms.
En resumen, ASP.NET MVC es un marco completamente nuevo para crear aplicaciones de ASP.NET, diseñadas desde cero hasta con SoC y capacidad de prueba en mente.
Cuando escribe una aplicación de ASP.NET MVC, pensar en términos de controladores y vistas.
Tomar sus decisiones acerca de cómo pasar datos a la vista y cómo exponer el nivel medio a los controladores.
El controlador elige qué vista para mostrar basándose en la dirección URL solicitada y datos pertinentes.
Cada solicitud se resuelve invocando un método en una clase de controlador.
No hay devoluciones de datos son nunca necesarios para atender una petición del usuario.
Viewstate no es nunca necesario para mantener el estado de la página.
No controles de servidor de cuadro negro arraysof existen para generar el código HTML para el explorador.
Con ASP.NET MVC, volver a explorar el buen gusto antiguo del Web: comportamiento sin estado, control total sobre todos los bits de HTML, secuencias de comandos total y libertad CSS.
Un motor independiente y reemplazable, genera el HTML que sirve al explorador.
No es ninguna dependencia en archivos del servidor físico de ASPX.
Archivos ASPX todavía pueden ser parte del proyecto, pero ahora sirven como plantillas HTML sin formato, junto con sus clases de código subyacente.
El motor de vista predeterminado se basa en el motor de procesamiento de formularios Web Forms, pero puede utilizar otros motores conectables como nVelocity o XSLT.
(Para obtener más detalles, tienen un aspecto en el sitio Web de MVCContrib en mvccontrib.codeplex.com).
El entorno de tiempo de ejecución es en gran medida la misma que en formularios Web Forms ASP.NET, pero el ciclo de solicitud es más sencillo y más directa.
Una parte esencial del modelo de formularios Web Forms, el ciclo de vida de página, ya no es necesaria en ASP.NET MVC.
Se debe tener en cuenta, sin embargo, que el motor de vista predeterminada de ASP.NET MVC todavía se basa en el motor de procesamiento de formularios Web Forms.
Éste es el truco le permite utilizar páginas principales y algunos controles de servidor en las vistas de MVC de ASP.NET.
Mientras el motor de vista se basa en formularios Web Forms, la vista es un archivo ASPX con una clase regular de código donde puede controlar eventos clásicos como Init, Load, PreRender, además de eventos de control específicos como RowDataBound para un control GridView.
Si cambia a desactivar el motor de vista predeterminado, ya no necesite Page_Loador otros eventos del ciclo de vida página estándar de.
figura 1 se compara la pila de tiempo de ejecución para formularios Web Forms y ASP.NET MVC.
Figura 1 La pila de tiempo de ejecución de un vistazo (haga clic en la imagen para ampliarla)
Se debe tener en cuenta que los cuadros de "Ciclo de vida de página" en la figura 1 se han contraído para mejorar la legibilidad y incluyan varios eventos adicionales cada.
De todos modos, la pila de tiempo de ejecución de ASP.NET MVC es más sencilla y la diferencia es debido a la falta de un ciclo de vida de página.
Sin embargo, esto facilita problemático para mantener el estado de elementos visuales entre solicitudes de página.
Estado puede almacenarse en caché o de sesión, pero se deja esta decisión al programador.
Figura 2
Muestra la secuencia de una solicitud de ASP.NET MVC.
Figura 2 El diagrama de secuencia de una solicitud de ASP.NET MVC (haga clic en la imagen para ampliarla)
El acrónimo MVC es el acrónimo Model-View-Controller.
Sin embargo, debe tener en cuenta que el patrón en la figura 2 muestra no coincide exactamente con la formulación clásico del patrón MVC.
En concreto, en el documento original MVC, modelo y la vista están ligados juntos a través de una relación Observer.
El patrón MVC, sin embargo, se define deliberadamente imprecisa y, incluso más importante aún, fue inventado cuando el Web todavía estaba proceder.
Adaptar MVC en el Web lo desplazó hacia el modelo en la figura 2 , que es también conocida como Model2.
En general, cuando habla o leer acerca de MVC ser tenga en cuenta que hay bastantes sabores ligeramente diferentes del mismo dentro de la documentación.
Inconvenientes de ASP.NET MVC
Por lo que ASP.NET MVC trae a la tabla un diseño limpio con una separación de preocupaciones ordenado, una pila de tiempo de ejecución leaner, control total sobre HTML, un nivel organizar de extensibilidad y un entorno de trabajo que permite, no penaliza, desarrollo controlado por pruebas (TDD).
¿Es ASP.NET MVC, por lo tanto, un paraíso para los desarrolladores Web?
Igual que con formularios Web Forms, lo que algunos perciben como un nivel de cifrado de ASP.NET MVC, otros pueden ver como un punto débil.
Por ejemplo, control total sobre HTML, JavaScript y CSS, ASP.NET MVC significa que introduce manualmente los elementos Web.
Gran parte de este dolor puede reducirse, sin embargo, con algunas de las bibliotecas de JavaScript más recientes y el motor de la vista incluso a distintos.
En general, sin embargo, no es ningún tipo de modelo de componentes para ayudarle con la generación de código HTML, como en el enfoque de formularios Web Forms.
Actualmente, los ayudantes HTML y controles de usuario son las herramientas sólo que se puede aprovechar para escribir más rápidamente código HTML.
Como resultado, algunos desarrolladores ASP.NET aparecer ASP.NET MVC que toma un paso hacia atrás en términos de productividad y facilidad de uso.
Otro punto de realizarse, sobre el impacto de ASP.NET MVC en desarrollo diaria, es que requiere familiarizado inicial con el patrón MVC.
Tiene que saber cómo funcionan conjuntamente los controladores y vistas en la implementación de ASP.NET.
En otras palabras, ASP.NET MVC no es algo que puede obtener fácilmente información experimentando.
En mi experiencia, esto puede ser el origen de productividad reducido para el desarrollador de formularios Web Forms de promedio.
La perspectiva derecha
Como arquitecto o programador, es esencial que entienda las diferencias estructurales entre los marcos de modo que puede tomar una decisión exhaustivo.
Con todo, ASP.NET Web Forms y ASP.NET MVC son funcionalmente equivalentes en el sentido de que un equipo cualificado puede correctamente utilizar cualquiera para crear cualquier solución Web.
Los conocimientos, educación y actitud del equipo, sin embargo, son los puntos claves que deben tenerse en cuenta.
Como se puede haber imaginado usted mismo, la mayoría de las características presenta como un signo más para cualquier marco de trabajo también puede verse como un signo menos y viceversa.
Control total sobre HTML, por ejemplo, puede ser una salvación a una persona pero una pesadilla a otro.
Personalmente, estaba horrorizado la primera vez que vio el contenido de una página de vista no trivial en ASP.NET MVC.
Pero cuando mostraba la misma página a un cliente se cuya aplicación sigue utilizando un número significativo de las páginas ASP, de bien, era libres.
Si tiene accesibilidad como un requisito estricto, probablemente desee tomar el control completo sobre el HTML que se muestra.
Y esto no es totalmente posible con formularios Web Forms.
Por otro lado, si está creando una aplicación controlada por datos gruesa, será éste es el conjunto de controles enlazados a datos y statefulness proporcionadas por formularios Web Forms.
Correctamente, Microsoft ha no coloca ASP.NET MVC como reemplazo para formularios Web Forms de ASP.NET.
Formularios Web Forms es definitivamente un patrón que funciona para las aplicaciones Web.
Al mismo tiempo, Ruby en Rails ha demostrado que MVC también puede ser un patrón correcto para aplicaciones Web; y ASP.NET MVC confirma esta.
Al final, formularios Web Forms y ASP.NET MVC tienen los profesionales de TI, inconvenientes y diferencias estructurales que afectan a varios niveles.
Generalizar, debería decir que formularios Web Forms abarca la filosofía de RAD, mientras que ASP.NET MVC está orientada a TDD.
Además, los formularios Web Forms va hacia una abstracción del Web que simula un entorno con estado, mientras que ASP.NET MVC aprovecha el dinamismo natural del Web y le guiará hacia la creación de aplicaciones que son intrínsecamente comprobable y correspondencia imprecisa descriptivo del motor de búsqueda y con control total de HTML.
¿Cuál es el modelo perfecto para ASP.NET?
Después de utilizar formularios Web Forms para años, reconoce un número de sus inconvenientes, y ASP.NET MVC los direcciones bastante bien: capacidad de prueba, el control HTML y separación de preocupaciones.
Pero aunque veo ASP.NET MVC como una opción válida en este momento, no cree que la viñeta de plata para cada aplicación Web.
En mi opinión, ASP.NET MVC hoy carece de cierto nivel de abstracción para crear partes estándar de HTML.
Aplicaciones auxiliares HTML son un intento interesante de acelerar la creación de HTML.
Espero ver en el futuro una nueva generación de controles de servidor de MVC específicas, como fácil y rápida de aprender y utilizar como controles de servidor de formularios Web Forms, pero totalmente independiente del modelo de devolución de datos y viewstate.
Mi esperanza es para un control de System.Web.Mvc.GridView me ahorra de escribir un bucle para generar una tabla HTML, mientras que ofrecen las plantillas de columna, los eventos de enlace de datos del servidor y las opciones de estilo.
¿Cuál será la diferencia entre tales un GridView de MVC y GridView de formularios Web de hoy?
El control GridView de MVC sólo podría emitir HTML Además, opcionalmente, algunos JavaScript específicas de fila, pero no administrar aspectos como la paginación y ordenación.
Paginación y ordenación será delegadas a otros controles específicos o vínculos sin formato creado por el desarrollador.
De esta forma, el control GridView de MVC se puede poner algunos sabor RAD a ASP.NET MVC, acelerar el desarrollo de páginas sin excluye adaptada páginas.
Volver a la raíz del problema, la diferencia clave entre formularios Web Forms y ASP.NET MVC es el modelo subyacente.
Formularios Web Forms es un modelo basado en el diseño "Controlador de página".
Formularios Web Forms son centrado en la interfaz de usuario y centrada en torno al concepto de una página: la página obtiene entrada, responde y determina el resultado para el explorador.
El entorno de desarrollo, por lo tanto, se diseñó para habilitar prototipos rápida, a través de asistentes y diseñadores enriquecidos.
Cualquier acción de usuario termina en un método en la clase de código subyacente de cada página.
En ese momento, sin embargo, nada impide utilizar SoC adecuado y realmente nada detiene a los arquitectos de imponer patrones como MVC, Model-View-Presenter (MVP) o incluso modelo vista-Vista modelo (MVVM).
La arquitectura de formularios Web Forms no promueve SoC, pero no impide bien.
La arquitectura de formularios Web Forms facilita seductive optar por arrastrar y colocar controles en la derecha de la lógica de código en códigos auxiliares de eventos sin más separación, y para colocar datos orígenes derecha en la página, que se acopla la interfaz de usuario directamente a la base de datos.
MVC ni se prohíbe ni un blasphemy en formularios Web Forms; es sólo que muy pocos desarrolladores practicarlo porque requiere solucionar gran parte de la infraestructura de formularios Web Forms.
Capacidad de prueba es un artículo diferente.
Formularios Web Forms ASP.NET no impide que las pruebas unitarias, pero requiere mucho disciple y repetitivo de codificación que so.As largo como código su forma SoC puede probar y reutilizar la presentación y la lógica empresarial.
Por supuesto, es probable que no tiene la plantilla de proyecto Visual Studio crear un proyecto de prueba para que.
Deberá familiarizarse con las pruebas y simulacro marcos y administrar los proyectos usted mismo.
Pero esto puede realizarse.
Desde una perspectiva de la capacidad de prueba, sin embargo, una diferencia existe entre formularios Web Forms y ASP.NET MVC.
En los formularios Web Forms, simplemente no tiene la flexibilidad de ASP.NET MVC.
Esto es una limitación es true.
ASP.NET MVC está diseñado con capacidad de prueba en cuenta, lo que significa que la arquitectura de framework guía al desarrollador escribir código que es intrínsecamente comprobable, que está aislado del contexto o conectado a, a través de interfaces contratadas.
Lo que es incluso más importante, en ASP.NET MVC objetos intrínsecos son mockable como exponen clases base y de interfaz.
Desde el punto de vista pruebas, lo mejor que puede hacer en formularios Web Forms es mover la lógica en clases independientes y puede probar fácilmente.
A continuación, para comprobar la presentación (ASPX y código subyacente), enviar solicitudes HTTP y comprobar los resultados.
Que no puede hacerlo en formularios Web Forms sin girando hasta el tiempo de ejecución completa de ASP.NET, sin embargo.
En ASP.NET MVC, la mayoría de las pruebas es garantizar que los datos pasados en la vista están correctos.
Además, puede simular los objetos intrínsecos y ejecutar las pruebas en un entorno aislado genuinely.
Se debe también tener en cuenta ese control a través de HTML y direcciones URL descriptivas SEO, ambos ventajas de ASP.NET MVC, hasta cierto punto en formularios Web Forms se puede conseguir.
En concreto, ASP.NET 3.5 SP1, incluye el enrutamiento de dirección URL y la API de historial para SEO.
Adaptadores CSS, en su lugar, son las herramientas para aprovechar para intentar control HTML en formularios Web Forms.
Integración con marcos de JavaScript y AJAX, Francamente, ya no es un problema en los formularios Web Forms.
Hechos undisputable
Formularios Web Forms ASP.NET y ASP.NET MVC no son competidores en el sentido de que se debe para reemplazar la otra.
Tendrá que elegir uno, pero diferentes aplicaciones pueden forzar realizar distintas opciones.
En el extremo es realmente como elegir entre un automóvil y una motocicleta al realizar un viaje.
Cada viaje requiere una elección y tener ambos vehículos disponibles debe verse como una oportunidad, no como una palabrota.
Éstos son algunos hechos acerca de los marcos de trabajo:
-
Formularios Web Forms es difícil probar.
-
ASP.NET MVC requiere administrar la generación de HTML en un nivel más detallado.
-
ASP.NET MVC no es la única manera para obtener SoC en ASP.NET.
-
Formularios Web Forms permite ir aprendiendo a medida.
-
ViewState se puede controlar o deshabilitar.
-
Formularios Web Forms se diseñó para abstraer la maquinaria de Web.
-
ASP.NET MVC expone arquitectura Web.
-
ASP.NET MVC se diseñó con capacidad de prueba y la inserción de dependencia en la cuenta.
-
ASP.NET MVC le hacia un mejor diseño del código.
-
ASP.NET MVC es joven y carece de un modelo de componente.
-
ASP.NET MVC no anti-Web formularios.
ASP.NET MVC no se creó para reemplazar formularios Web Forms pero asociado a él.
ASP.NET MVC activa algunos de los elementos más débiles de formularios Web Forms en sus propios puntos fuertes internos.
Sin embargo, problemas, como falta de capacidad de prueba, SoC, SEO, y el control HTML se puede evitar o reducir en formularios Web Forms con algunos disciplina y un buen diseño, aunque el marco de trabajo no proporciona suficiente guía.
Al final del día
Hemos visto que hay ventajas y desventajas en formularios Web Forms y ASP.NET MVC.
Sin embargo, muchos desarrolladores, parecen favorecer ASP.NET MVC porque representa la única forma de obtener SoC y capacidad de prueba en sus aplicaciones.
¿Es realmente la única forma?
Nº
Sin embargo, ASP.NET MVC hace más fácil y natural para lograr SoC y escribir más código comprobable.
ASP.NET MVC mágicamente se no transformar el todos los desarrolladores en un arquitecto experto y no impide que los desarrolladores escribir código diseñado recargado y mal.
Al final del día, formularios Web Forms y ASP.NET MVC ayudan a crear aplicaciones que son diseñadas e implementadas para tratar eficazmente la complejidad de soluciones del mundo real.
No existe mágico de software y ninguno es compatible aún con la plataforma de ASP.NET.
Dino Esposito es un arquitecto de IDesign y coautor de Microsoft .NET: Architecting Applications for the Enterprise (Microsoft Press, 2008).
En función de Italia, Dino es ponente habitual en eventos del sector en todo el mundo.
Puede unirse a su blog en
weblogs.ASP.
net/despos
.
|
|
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.
|