¿Están los formularios web de ASP.NET barridos debajo de la alfombra para hacer espacio para mvc?

Question

He leído toda la información de marketing acerca de cómo mvc y formularios web son complementarios, etc.

Sin embargo, parece que todos los blogs hablan sobre mvc y la única noticia que sale es sobre mvc.

¿Microsoft continuará mejorando webforms como ciudadano de primera clase o solo será una tecnología compatible a medida que muevan todos sus esfuerzos reales, desarrolladores y recursos a mvc en el tiempo?

¿Existe alguna evidencia real de nuevas mejoras emocionantes para las webforms en el futuro cercano?

Answer 1

Estuve en una conferencia (Remix 08) y Scott Gu dijo que definitivamente continuarán apoyando ambos métodos y que MVC no era apropiado para cada aplicación. Scott dijo que había una serie de mejoras para el modelo de formularios web (aunque no dijeron lo que eran).

El modelo de formularios web no desaparece porque:
El modelo de formularios web es mejor para algunos tipos de aplicaciones, p. pequeñas aplicaciones, aquellas que requieren largos procesos que hacen uso de estado de vista útil
Muchas aplicaciones están utilizando
Muchos de los componentes de terceros desarrolladas para que
aplicación ASP.net no está maduro todavía (aunque sí parece bastante bueno hasta ahora)

Microsoft probablemente anuncie una serie de nuevas características en PDC dentro de unas semanas.

Answer 2

Microsoft finalmente está llegando a un acuerdo sobre un hecho básico de desarrollo. No puede proporcionar la mejor solución a ningún problema. Esta es la razón por la cual se está desarrollando MVC, y Scott Guthrie está afirmando claramente que MVC está diseñado para sitios más grandes y empresariales. Los formularios web continuarán existiendo y se desarrollarán como un enfoque simple basado en RAD para el desarrollo web.

Si das un paso atrás y revisas todas las mejoras y adiciones recientes a la pila de Microsoft, puedes categorizarlas fácilmente entre estas dos clases. Por ejemplo:

• acceso de datos: LINQ a SQL vs ADO.NET Entity Framework
• Remoting: WCF vs WebServices
• LiveID: LiveID (web) vs autenticación autenticación RPS
• ...

Solo espero que Microsoft aclare esta distinción con el tiempo, porque parece haber mucha confusión entre los desarrolladores sobre qué herramienta se debe elegir para cada tarea.

En conclusión, creo que Microsoft seguirá desarrollando ambos porque atienden a diferentes perfiles de desarrollador. Obviamente, Microsoft tiene un gran interés en hacer crecer su base de desarrolladores tanto como sea posible y en hacer que la pila .NET sea lo más útil posible.

Answer 3

Voy a salir de una extremidad aquí y estoy en desacuerdo con la idea general de que MVC es el marco de "empresa" aquí o de alguna manera es el mejor de los dos.

MVC is great! Pero solo mira el nombre. Significa "Modelo, Vista, Controlador" ... ¿ves la "vista" allí?

Ahora mira la competencia, "Formularios web" ... ¿ves las "formas" en esa?

MVC hace un gran trabajo en situaciones tipo "ver". Para los sitios que publican contenido ("vistas" de información) MVC probablemente tiene una ventaja, especialmente para sistemas más grandes que necesitan muchas pruebas y un diseño muy formal para admitir la conmutación inteligente de vistas.

Para las aplicaciones que interactúan fuertemente con el usuario a través de formularios (recopilación de datos y aplicaciones pesadas de entrada de datos), los formularios web tienen una ventaja debido al uso inherente de publicaciones de formularios como mecanismo principal.

Si bien puede hacer vistas con formularios web y puede hacer formularios con MVC, cada uno tiene sus compensaciones. En el estado actual de MVC, encuentro que escribir "vistas" de entrada de datos pesados ​​es mucho más difícil y doloroso que con formularios web ... y no me refiero un poquito.

En el futuro, espero ver a MVC mejorar frente a los escenarios de entrada de datos, pero estos escenarios probablemente tendrán un precio bastante alto en comparación con aquellos con formularios web.

Ninguno de los dos es más "empresarial" que el otro por lo que puedo decir ... lo que más me interesa es seguir usando aplicaciones híbridas que utilicen MVC para la visualización y publicación del negocio mientras que los formularios web se usan más naturalmente para el extremo de entrada de datos pesados ​​... todo en el mismo proyecto web ... Espero que veamos algo así.

Answer 4

Antes de que comenzara a difundirse el concepto de MVC framework, pasamos una gran cantidad de tiempo en mi empresa desarrollando nuestro propio .NET MVC framework.

Esto se debía a que no queríamos estar limitados por las limitaciones de la abstracción de WebForms: queríamos evitar la sensación de "torpeza" y los compromisos de la interfaz de usuario que WebForms parece imponer a las aplicaciones más personalizadas. Además, queríamos URI amigables y queríamos una mejor separación entre el front-end y el back-end que la ofrecida por WebForms (establecimos una arquitectura XML/XSLT).

En mi opinión, los WebForms ofrecen un método mucho más pobre de interactuar con el usuario específicamente debido al uso de ViewState, PostBacks, etc. que abstraen la mecánica real de HTTP del desarrollador, esto les da menos latitud en cómo permiten que los usuarios interactúen con el sistema. El ejemplo clásico es que debido a que las páginas de WebForms son casi siempre el resultado de un POST, si el usuario intenta actualizar la página, el usuario recibe un desagradable mensaje de advertencia del navegador. El patrón en el mundo del desarrollo web tradicional para lidiar con esto siempre ha sido incluir una directiva 302 Redirect en la Respuesta HTTP, por lo tanto, se ha mantenido el paradigma HTTP original de GET para la recuperación de datos y POST para el envío de datos. Existen otros problemas similares, como la imposibilidad de tener dos formularios en una página (por ejemplo, un formulario de inicio de sesión en un sitio web en un servidor diferente).

Dicho esto, para RAD, los WebForms son geniales. Actualmente estoy desarrollando la aplicación de administración para una aplicación web que hemos desarrollado utilizando nuestro framework MVC personalizado, y estoy volando ya que todo lo que necesito es mostrar el contenido de una carga de tablas de la base de datos y, en algunos casos, permitir que el usuario para editarlos, de diferentes maneras.

Creo que si tenemos que convencernos de que MS va a seguir siendo compatible con WebForms, piense en todos los desarrolladores anteriores de Windows. Estas son las personas para las que se desarrolló originalmente WebForms, y no desaparecerán. Los desarrolladores corporativos serán su salvador si usted es un fan de WebForms.

Answer 5

Usted podría hacer peor que echar un vistazo a cargo de Phil Haak a partir de noviembre:

The Future of WebForms and ASP.NET MVC

Señala 5 cosas claves anounced bajo ASP.NET en el PDC año pasado:

1. infraestructura principal incluyendo escala y rendimiento
2. Web Forms incluyendo problemas con los ID de cliente, ViewState, el uso de CSS, etc
3. AJAX
4. datos y Dynamic Data
5. MVC

Junto con eso, hay son cosas que se han creado como parte de ASP.NET MVC que ya se han lanzado para formularios web como el módulo de enrutamiento que será de gran ayuda en algunos de mis proyectos ts, incluso sin usar MVC.

Además de eso, también hay una serie de cambios en VS2010 que deberían ayudar a los desarrolladores web a utilizar WebForms o MVC, lo que sería bueno.

Los blogueros tienden a hablar sobre lo que es brillante y "nuevo", así es como van las cosas. Seguro que verás muchas palabras escritas al respecto, aunque MVC no es un nuevo patrón de diseño. se remonta a al menos 30 años.

Lo mismo podría decirse de WPF/Silverlight: ¿son asesinos de WinForms/WebForms? No. Son ofertas alternativas, con algunos beneficios sobre la manera anterior de hacer las cosas, pero también con algunas diferencias/inconvenientes.