Cuándo favorecer ASP.NET WebForms sobre MVC

Webforms vs. MVC parece ser un tema candente en este momento. Todos los que conozco promocionan MVC como la próxima gran novedad. Por mis ligeras incursiones en él, parece estar bien, pero no, no creo que sea el final de los formularios web.

Mi razonamiento, y el razonamiento de por qué los formularios web se elegirían en lugar de MVC, ha más que ver con una perspectiva empresarial que con lo que una es mejor que la otra.

El tiempo y el dinero son las principales razones por las que se elegirían los formularios web en lugar de MVC.

Si la mayoría de sus El equipo conoce los formularios web y usted no tiene tiempo para ponerlos al día en MVC, el código que se generará puede no ser de calidad. Aprender los conceptos básicos de MVC y luego saltar y hacer esa página compleja que necesita hacer son cosas muy diferentes. La curva de aprendizaje es alta, por lo que debe tenerlo en cuenta en su presupuesto.

Si tiene un sitio web grande escrito en formularios web, es posible que esté más inclinado a crear páginas nuevas en formularios web para que no lo haga » t tiene dos tipos de páginas muy diferentes en su sitio.

No estoy diciendo que sea un enfoque de todo o nada, pero hace que su código sea más difícil de mantener si hay una división de ambos , especialmente si no todos los miembros del equipo están familiarizados con MVC.

Mi empresa hizo recientemente tres páginas de prueba con MVC. Nos sentamos y las diseñamos. Un problema que encontramos es que la mayoría de nuestras pantallas tienen la funcionalidad Ver y Editar en la misma página. Terminamos necesitando más de un formulario en la página. No es problema, excepto que no usaríamos nuestra página maestra. Tuvimos que renovar eso para que tanto las páginas de formularios web como las páginas MVC pudieran usar la misma página maestra para una apariencia común. Ahora tenemos una capa extra de anidación.

Necesitábamos crear una estructura de carpetas completamente nueva para estas páginas para que siguiera la separación MVC adecuada.

Sentí que había demasiados archivos para 3 páginas, pero esa es mi opinión personal.

En mi opinión, elegiría formularios web en lugar de MVC si no tiene el tiempo / dinero para invertir en actualizar su sitio para usar MVC. Si hace un enfoque medio arsado para esto, no será mejor que los formularios web que tiene ahora. Peor aún, incluso podría estar preparando esta tecnología para fallar en su empresa si se estropea, ya que la alta dirección podría verla como algo inferior a lo que saben.

Comentarios

• Esta es una buena respuesta. Le di +1 porque se agradecen sus experiencias personales. Pero esto es un fracaso debido a la falta de experiencia / conjunto de habilidades de los desarrolladores que pedí evitar . No estoy convencido de que Microsoft opte por no marcar una tecnología como obsoleta simplemente por temor a la curva de aprendizaje de MVC. Este puede ser el caso, pero ‘ todavía no convencido.
• @ P.Brian.Mackey – No ‘ t dije que el desarrollo de formularios es más rápido que MVC. Usted pidió dejar ese argumento fuera de él. Discutir el tiempo y el dinero para capacitar a su personal es un argumento diferente. MS no ‘ t marcará los formularios web como obsoletos por una gran razón: los clientes empresariales han pasado años desarrollando clientes web en formularios web y han ganado ‘ No le agrada tener que invertir tiempo y dinero para actualizar.
• @Raynos: si todos los miembros del equipo eran competentes en MVC y su empresa estaba iniciando un nuevo proyecto, entonces la única razón por la que podía ver a alguien eligiendo formularios web es por elección personal.
• Conozco ambas tecnologías íntimamente. Todos mis proyectos web se hacen con mvc y trabajo en una empresa donde tengo rienda suelta para hacer lo que sea mejor. Siempre elijo MVC.
• Empecé con Webforms y una vez que descubrí MVC cambié a eso. No ‘ no sé cómo alguien podría defender los formularios web. ¿Ciclo de vida de la página y un formulario para toda la página? ¿Me estás tomando el pelo? El constructor de sitios de Yahoo era probablemente el cliente previsto para él, pero ni siquiera ellos ‘ querían esa basura.

Desarrollé aplicaciones ASP .Net WebForms durante 3 años, y después de un día de hacer un tutorial de MVC me vendieron. MVC es casi SIEMPRE la mejor solución. ¿Por qué?

• El ciclo de vida de la página es más simple y más eficiente
• No existen controles además de los controles html. No es necesario depurar su salida para ver qué está generando ASP .Net.
• Los ViewModels le brindan un poder inmenso y evitan la necesidad de realizar un enlace de control manual y eliminan muchos errores relacionados con el enlace.
• Puede tener varios formularios en una página. Esta fue una limitación seria de WebForms.
• La web no tiene estado y MVC se adapta más a la arquitectura de la web. Webforms presenta el estado y los errores lo tiene con la introducción de ViewState. ViewState es automático y funciona en segundo plano, por lo que no siempre se comporta de la manera que usted desea.
• Las aplicaciones web necesitan trabajar con ajax en estos días. Ya no es aceptable tener cargas de página completas. MVC hace que ajax sea mucho mejor, más fácil y más eficiente con JQuery.
• Porque puede tener múltiples formularios en una página, y porque la arquitectura es impulsado por llamadas a URL, puede hacer cosas divertidas como ajax cargar un formulario diferente, como editar un formulario en su página actual usando JQuery. Una vez que se dé cuenta de lo que esto le permite hacer, puede hacer cosas increíbles fácilmente.
• ASP .Net WebForms no es solo una abstracción sobre html, es extremadamente compleja. A veces, se obtiene un error extraño y se lucha con él durante mucho más tiempo del necesario. En muchos casos, se puede ver lo que estaba haciendo mal pero no puedes hacer nada al respecto. Terminas haciendo soluciones extrañas.
• WebForms no es una buena tecnología para los diseñadores. A los diseñadores a menudo les gusta trabajar con html directamente. En MVC es una vista, en WebForms es medio día de trabajo.
• Dado que la plataforma web está evolucionando rápidamente, los WebForms no se mantendrán al día. consciente de las nuevas etiquetas o características de HTML5, seguirá procesando lo mismo a menos que obtenga (a menudo) costosos controles de terceros o espere a que Microsoft emita una actualización.
• Los controles en WebForms lo limitan de muchas maneras. En MVC, puede simplemente tomar una biblioteca JQuery e integrarla en sus plantillas.

Sé que algunos de los problemas anteriores se han abordado hasta cierto punto a medida que evoluciona WebForms, pero esa fue mi experiencia original. En general, me resultaría extremadamente difícil encontrar un caso de negocios para WebForms a menos que un proyecto ya lo esté usando.

Comentarios

• +1 para señalando múltiples formas. Además, el hecho de que los formularios web HTML generan la mayoría de las veces no es muy amigable con el SEO (como en: grandes trozos de estado de visualización en la parte superior de la página)
• Tengo que estar 100% de acuerdo con esta respuesta. Al final del día, WebForms hace que hacer las cosas en el lado del cliente (html / navegador) sea mucho más difícil. Literalmente tienes que luchar contra el marco para hacer algunas cosas. Una página aspx termina con mucho más código debido a los controles del servidor que lo que normalmente hace una página cshtml. @ šljaker Si empiezas a desactivar ViewState y evitas los controles del servidor, ‘ has abandonado gran parte de WebForms en ese momento. No ‘ no veo ese argumento como particularmente convincente.
• Puede tener controles html sencillos en WebForms, nadie lo obliga a usar los controles del servidor. Puede tener un formulario web sin estado completo, nadie lo obligará a usar ViewState. Puede usar ajax completo y jQuery en formularios web, nadie le está restringiendo el uso de jQuery. Puede implementar el enrutamiento de URL, nadie lo obligará a usar una URL base de archivo estático. Dibujar manualmente una página con CSS consume tanto tiempo como MVC necesitaba. Puede diseñar una página HTML directamente en Webform.
• @mjb: si no ‘ t usa controles de servidor, ViewState, etc., ¿por qué usar WebForms cuando MVC está más cerca de lo que ‘ estás haciendo? Es ‘ es como conducir un tractor al trabajo, pero sin hacer ningún todoterreno o usar la pala / azadón o las barras estabilizadoras. En ese momento, ¿por qué no usar un automóvil?
• @Tjaart No es del todo correcto que no pueda tener múltiples formularios en la página ASPNET.Puede tener tantos formularios como desee en la página ASPNET, pero solo puede tener un formulario de servidor: formulario con runat = » servidor » atributo.

Le envié un correo electrónico a Scott Guthrie , un experto en MVC de Microsoft. Y probablemente el hombre más calificado para responder a esta pregunta. Tuvo la amabilidad de responder:

«Diferentes clientes buscan diferentes enfoques de programación y muchos aman WebForms y piensan que es genial. A otros les encanta MVC y creo que es genial. Por eso estamos invirtiendo en ambos «.

Entonces, para mí, esto dice que no es un problema técnico. Es más un «tema suave», por así decirlo. Uno de preferencia personal. Esto está en línea con lo que varios de ustedes han dicho.

Gracias por todas las respuestas.

Comentarios

• Scott Guthrie inventó el marco MVC para ASP.NET durante un vuelo de regreso de Londres a Seattle en 2006/7. Ahora que lo pienso, prácticamente inventó .NET también ( en.wikipedia.org/wiki/Scott_Guthrie ). Llamarlo » experto » es una subestimación enorme 😉
• Eso ‘ una buena respuesta política de Scott Guthrie. Si él mismo estuviera invirtiendo su propia aplicación web, ‘ verías un proyecto MVC y cualquier cosa que no ‘ no se pudiera hacer en MVC, Silverlight sería la alternativa. No ‘ no tome esto como un comentario negativo hacia WebForms, creo que los WebForms son excelentes para aplicaciones internas de menor alcance que pueden beneficiarse de componentes de terceros como los creados por Telerik. ‘ me alegra que Microsoft esté avanzando con ambas tecnologías.
• » Scott Guthrie inventó el marco MVC para ASP .NET durante un vuelo » Creo que eso realmente trivializa MVC. No ‘ no conozco a Scott Guthrie, pero ‘ estoy dispuesto a apostar que había estado preguntando cómo MVC podría implementarse en ASP.NET durante un tiempo, y usé ese largo vuelo para implementar un prototipo básico como prueba de concepto.
• » Es por eso que estamos invirtiendo en ambos. » Y cuando veamos que los formularios web comienzan a declinar, lo descartaremos sin piedad porque invertir en un producto finalmente muerto no es lo mejor para nuestro negocio.
• Hasta ya no se enseña en las escuelas, durante muchos años, siempre será aplicable en el mundo empresarial. Las universidades y las escuelas secundarias continúan ofreciendo cursos de introducción y avanzados en vb.net. ¡¡¡NO va a ninguna parte !!!

Esta es una pregunta obsoleta con muchas respuestas pero ninguna. tenía la respuesta que esperaba que apareciera en la lista.

La respuesta corta es:

• Use ASP.NET MVC si tiene la intención de construir correctamente una aplicación web con programación moderna convenciones y patrones adoptados por la industria para la plataforma ASP.NET. En el lado negativo, se esperará que sepa cómo funcionan HTML y los recursos del lado del cliente (Javascript, CSS), así como que acelere la mentalidad de programación MVC, que tiene una curva de aprendizaje empinada pero llega a un final repentino una vez que se comprende.
• Use ASP.NET Web Forms si «está usando o desea usar una GUI centrada en RAD (Desarrollo rápido de aplicaciones) , enfoque de arrastrar y soltar para crear un prototipo de algo muy rápidamente, es decir, el comportamiento de un botón / cuadrícula de datos se conecta en 15 minutos, y la solución no pretende ser algo compatible con desarrolladores. O Use ASP.NET Web Forms si tiene experiencia en GUI o desarrollo de Windows Forms y desea transferir su conocimiento a la Web.

Pero para ver esto correctamente, debe comprender la historia de cada uno.

ASP.NET Web Forms fue la respuesta de Microsoft a aquellos que habían estado construyendo aplicaciones web dinámicas usando Visual Basic 6 Ac controles tiveX, DLL VB6 en el servidor y ASP Classic. En ese momento, el desarrollo web con estas herramientas de Microsoft era un verdadero desastre. Junto con la totalidad de .NET Framework, que fue el resultado de Microsoft esencialmente volviendo al tablero de dibujo sobre cómo hacer una programación comercial productiva en la pila de Windows, ASP.NET Web Forms fue, en su día, asombroso y hermoso.

Todo el enfoque fue dar a los desarrolladores lo mejor de ambos mundos de algo muy similar al desarrollo de aplicaciones de Windows, pero con el poder de los servicios de Internet.La idea era que, al igual que con un «Formulario» (una ventana) de VB6 / WinForms, también una página web es un formulario (como una ventana, ver) , y en ese formulario podía arrastrar y soltar etiquetas, cuadros de texto, cuadrículas de datos, botones y otras cosas a las que estaban acostumbrados los desarrolladores de GUI de VB / WinForms.

Para hacer que un botón haga algo, después de arrastrarlo y soltarlo, simplemente haga doble clic en él en el diseñador y listo, estará en el editor de código, indicándole al formulario qué hacer cuando ese «clic «ocurre. Así fue exactamente como los desarrolladores de GUI de Windows crearon software usando herramientas de GUI de VB6 y herramientas de la competencia, excepto que ahora el código se está ejecutando en el servidor. ¡Guau!

Esta fue la tecnología de 2002. Increíble y hermosa en su momento como una respuesta a Internet -activó las soluciones GUI para el desarrollo RAD , trajo una sensación de poder a un mundo desordenado de desarrolladores de software que tenían objetivos comerciales que debían lograr.

Desafortunadamente, este modelo de programación enfatiza tanto la metáfora de la programación de GUI de Windows que lleva consigo la carga de los detalles de implementación necesarios , todo el pesado equipaje nec Es necesario acomodar los ciclos de vida de los eventos y esconder los desagradables detalles del código HTML y la secuencia de comandos que estos controles y componentes de arrastrar y soltar generarían. Y al final del día, los desarrolladores que soportan aplicaciones reales inevitablemente tenían que profundizar en estos componentes o escribir los suyos propios y, en consecuencia, pelearían batallas con esta infraestructura, batallas que dejarían atrás montones sobre montones de cruft, pelo tirado y lágrimas.

Retrocede. Lávese las manos. Veamos nuevamente el problema empresarial. ¿Cuáles son nuestros objetivos comerciales?

Necesitamos crear y administrar aplicaciones web . Nuestras limitaciones son que tenemos la World Wide Web, que se basa en HTTP, HTML, Javascript y CSS, y en el servidor tenemos reglas comerciales, bases de datos y un pequeño puñado de excelentes lenguajes de programación (por ejemplo, C #). ¿Realmente necesitamos esta metáfora de la GUI de Windows para impulsar nuestra metodología de desarrollo? ¿Por qué no podemos simplemente centrarnos en los problemas de la aplicación y eliminar las metáforas de la GUI?

Aquí es donde entra ASP.NET MVC. Comenzó por una rebelión de desarrolladores que se llamaban a sí mismos «Alt.Net» que querían volver a principios de desarrollo de software puros y adecuados. No más líos y líos, solo concéntrese en los objetivos comerciales y las mejores prácticas de software.

Lo que esto realmente se traduce en este caso es:

1. Separación de preocupaciones . Por ejemplo, un componente de datos no necesita saber cómo se procesarán sus datos, ni el marcado de la vista debe estar cargado con detalles de configuración de conexión de base de datos, y de esta manera un desarrollador puede enfocarse en su área de interés al editar y código de prueba.
2. Exposición y soporte completo para la exposición al meollo de HTML y recursos relacionados . En Web Forms, HTML está escondido, los desarrolladores no se animan a preocuparse por eso. En ASP.NET MVC, se anima a los desarrolladores a gestionar esos detalles; de hecho, es una necesidad. La ventaja aquí es que el desarrollador puede volver a aprender a apreciar la semántica limpia de HTML, CSS y script, y trabajar con en lugar de en contra.
3. Comprobabilidad de objetos comerciales . Los controladores y modelos son mucho más adecuados para las pruebas de unidades programáticas, de modo que las implementaciones se pueden validar para cumplir con los objetivos comerciales y se puede verificar que los cambios no se rompan. Con Web Forms era difícil probarlos, ya que los componentes no estaban diseñados para probarse individualmente y todo el resultado del desarrollo giraba en torno a formularios de página y sus ciclos de vida de eventos con la locura de la lógica empresarial y la lógica de presentación profundamente entrelazadas.

Tenga en cuenta que HTML ya es un lenguaje de marcado de muy alto nivel, al igual que Javascript, un lenguaje de programación de alto nivel. Toda la historia habría sido diferente si estuviéramos tratando con lenguaje ensamblador y C.

Ampliando el # 2, entonces, otro objetivo de ASP.NET MVC es permitir a los desarrolladores organizar los detalles del front-end de la parte de «ver» de sus soluciones y aprovechar la rica base que el resto de la industria ha construido sobre la plataforma de cliente de front-end.

Encontrará que los desarrolladores de ASP.NET MVC se sienten como en casa utilizando bibliotecas de Javascript enriquecidas y técnicas de creación de plantillas del lado del cliente sin tener que luchar con la arquitectura del lado del servidor. Este no fue originalmente el caso de ASP.NET Web Forms, porque Web Forms no quiere que mires el HTML o el script en absoluto, excepto si realmente tienes que hacerlo , en cuyo caso, ten cuidado, no es para los débiles de corazón. .

Comentarios

• Esta es una buena respuesta, pero los números 1 y 2 son incorrectos (WF no requiere que un componente sepa dónde están sus datos proviene, es una opción y siempre ha agregado HTML a sus archivos ASPX para admitir las etiquetas asp que está representando. Nunca ha necesitado profundizar y luchar contra los controles a menos que esté tratando de acceder a una función ASP no destinada al desarrollador interacción. Los puntos importantes son la capacidad de prueba y el patrón de diseño.)

Soy un conversor completo y total a ASP.NET MVC y no he mirado hacia atrás, eso dijo que todavía tengo que mantener varias aplicaciones WebForms muy grandes. Aquí está mi opinión:

WebForms
Úselos cuando tenga una vida muy pesada que ver con las cuadrículas. Los controles de cuadrícula son realmente muy agradables cuando tiene un conjunto de datos simple que encaja perfectamente en un formato tabular y desea proporcionar una forma sencilla para que los usuarios actualicen los registros. Sí, sé que MVC 4 tiene un tipo de lista Ajax realmente elegante que puede usar y que funciona muy bien, pero, en nuestro negocio, a menudo necesitamos hacer que algo funcione ayer y las buenas cuadrículas antiguas funcionan muy bien y los usuarios están felices de estar capaz de marcar una cuadrícula con alegría. Para mí, eso es lo mejor de WebForms para mí; pero, como Ryan señaló, los WebForms pueden ser un gran lío porque estás jugando en ambos lados de la valla de un ingenioso archivo de código subyacente. Puede ser tanto una rosa como una espina al mismo tiempo para mantener todas las cosas de tipo controlador entremezcladas con sus vistas.

MVC
Use esto cuando realmente quiera rodar el suyo y tenga la oportunidad de iniciar una aplicación desde cero. Tener una aplicación MVC claramente definida es un poco más de trabajo para comenzar, pero sus beneficios en la capacidad de mantenimiento superan el costo de configuración inicial. Si desea realizar interacciones Ajax interesantes, prefiere escribir su modelo con código, como direcciones URL limpias y rutas, y poder controlar todo el flujo de su aplicación, este es definitivamente el camino a seguir. Se necesita algo de tiempo para acostumbrarse al principio, pero creo que es la mejor opción para aplicaciones totalmente nuevas.

En conclusión, para mí, todo se reduce a grids y! grids. 🙂

Comentarios

• +1 para la bonita imagen entregada con » reproduciendo ambos lados del valla de un ingenioso archivo de código subyacente «.
• Muy útil este. ‘ estoy haciendo una aplicación basada en cuadrícula muy pesada y ‘ he descartado silverlight, xbap y se redujo a un show entre estos dos.

Mi experiencia:

• Escribí proyectos de CakePHP durante un año.
• Completó un proyecto de formularios web de tamaño medio durante seis meses.
• Trabajó en un proyecto de formularios Windows Forms durante tres años.

Después En esa experiencia, intenté escribir otra aplicación usando formularios web y me frustré después de luchar durante aproximadamente un día con la forma en que los formularios web intentan proteger al desarrollador de la realidad de que están desarrollando una aplicación que usa html, javascript y css.

Luego probé MVC, y teniendo un control más directo sobre la salida (y algo de experiencia con el paradigma MVC de CakePHP) pude completar esa sencilla aplicación exactamente como la quería en aproximadamente 1/2 día.

La disponibilidad de potentes marcos de interfaz de usuario como jQuery en gran medida eli Minina el atractivo de ceder el control directo de la salida en favor del uso de componentes de IU preconstruidos a menudo voluminosos.

Comentarios

• @JimG – Uhh , cualquier cosa que implique que una persona ingrese registros sin asociaciones interesantes en una base de datos, y que esa persona u otra persona los lea / imprima en algún otro punto puede básicamente ser andamio usando un marco MVC. Por supuesto, eso no es ‘ t la mayoría de las aplicaciones, pero ‘ es mucho más de lo que puede hacer con Formularios. Supongo que tu -1 prueba mi punto.
• Eso ‘ es 1/4 de día.
• Pero si los requisitos ascienden a » Necesito una aplicación con dos funciones, una para registrar información y la otra para verla, y no ‘ realmente importa cómo se ve. » Entonces, sí, eso ‘ es bastante factible.
• Lo siento, pero Desarrollar una aplicación de formularios web para ingresar datos y verlos es tan simple que se puede hacer en unas pocas horas. Crear la estructura de una aplicación MVC, Controladores, Vistas y Acciones, tomaría la misma cantidad de tiempo, pero no lo llevará a un producto terminado.
• @Dementic Por lo general, para una aplicación MVC simple, uno construye modelos, luego aplica scaffolding a los controladores y vistas y / o genera controladores / vistas scaffold. No hay nada que lleve mucho tiempo.

Prefiero los formularios web porque mi experiencia es el desarrollo de Windows.

La velocidad de desarrollo es un tema clave, y puedo pasar fácilmente un problema a alguien en la India para que lo solucione de la noche a la mañana con formularios, también, si tengo un problema de velocidad en una página, un libro realmente bueno sobre asp.net la velocidad es útil (Rick Kiessig es el hombre).

webforms es para gente de Windows ex mvc es para gente de web

pero, en el mundo moderno, donde Rick ha escrito un libro increíble , con servidores que aumentan diariamente de velocidad y codificadores baratos en India, bueno, los formularios web tienen la ventaja

Mis 2 centavos son para usar siempre ASP.NET MVC para nuevos proyectos si tiene la opción. En mi opinión, los formularios web no son una buena manera de desarrollar aplicaciones web, punto.

Creo que abstraer el REST básico es malo, todo el modelo de devolución de datos es malo, la forma en que html / css se maneja con confianza en el editor de GUI es malo, el énfasis en cosas como asistentes y GUI para configurar cosas es malo, las URL son malas.

Comentarios

• ¿Podría explicar con más detalles por qué cree eso?
• Creo que la abstracción de REST básica está de vuelta, todo el modelo de devolución de datos está de vuelta, la forma en que html / css se entrega con una dependencia del editor de GUI es mala , el énfasis en cosas como asistentes y GUI para configurar cosas es malo, las URL son malas, etc., etc.

He leído todas las respuestas y siento que mi experiencia personal agregaría algo a las respuestas anteriores.

Hace 3-4 años, desarrollé 2-3 proyectos de sitios web usando Webforms. Alrededor de ese tiempo, MVC no estaba cerca o no había oído hablar de él. El desarrollo fue naturalmente (venía del desarrollo de formularios Win sin experiencia previa en desarrollo web) rápido para mí, ya que no necesito aprender HTML en detalles y los controles web ayudaron mucho (muchísimo, me hizo la vida más fácil) .

Ahora, después de todo ese tiempo, no estaba trabajando en ningún proyecto web hasta hace poco y simplemente estaba construyendo una aplicación de Windows usando WPF.

Hace unos días tuve una idea para un sitio web y pensé en desarrollarlo: esta vez en MVC (ya que se habla en todas partes, además de que yo necesitaba aprender, así que elegí MVC). El proyecto aún está en fase de desarrollo, ya que todavía estoy aprendiendo y construyendo juntos.

Entonces, las diferencias clave que encuentro entre ambos son las siguientes: –

• Para alguien que viene del desarrollo de Windows, los formularios web siempre serán favorables. Asp La curva de aprendizaje de .net para un desarrollador de Windows es un poco empinada

• Para alguien que viene del desarrollo web en alguna otra tecnología, MVC se verá favorecido ya que se burla de th El último de todos ellos.

• El desarrollo es más fácil y limpio en MVC si está equipado con un buen conocimiento de HTML y CSS

• La implementación sigue siendo un problema. En los formularios web, solo se necesita copiar y pegar. Pero, esto requiere que se hagan algunas cosas.

En resumen, ambos permanecerán aquí por un tiempo.

Todavía no he visto esta consideración entre las 15 respuestas existentes a este hilo, pero creo que Vale la pena considerarlo.

Desde mi experiencia, Web Forms es más similar a Win Forms y WPF que MVC. Dado esto, creo que uno podría considerar elegir Web Forms cuando el equipo tenga más experiencia en ese tipo de tecnología, o cuando el proyecto de Web Forms entregará una interfaz al mismo conjunto de datos que un Win Forms existente (o desarrollado simultáneamente) o Proyecto WPF. Hacerlo permite a los desarrolladores cruzar entre proyectos más fácilmente, ya que la lógica de la aplicación puede ser bastante similar entre los dos.

Como han señalado otras respuestas, el desarrollo en el marco MVC es más similar al desarrollo web en Ruby, PHP, Python, etc. que sus homólogos de Microsoft; así que, naturalmente, la elección de MVC puede verse influenciada por la experiencia de los equipos en esas áreas, junto con los factores presentados en otras respuestas.

Comentarios

• + 1 Sin duda, un argumento razonable para los formularios web. Mi temor es que los equipos sigan esta mentalidad para evitar aprender cosas nuevas. MVC está lleno de muchos patrones que pueden ser desconocidos para un equipo. Aprender este tipo de patrones e implementarlos conduce a una mejor adherencia a los principios SOLID, lo que se traduce en una mejor capacidad de mantenimiento general. Estas técnicas probadas son también la clave real para la reutilización.

Nuestra razón para no ir para MVC hace unos años era una tecnología inmadura de Microsoft. En los últimos años, ahora estamos en una versión más madura (4) y MS parece haber descubierto hacia dónde van con esto.Sin embargo, todavía somos reacios a desarrollar aplicaciones de LOB importantes usando MVC ya que las características que queremos usar en la versión 4 requieren un servidor Windows 2012 (con respecto a los sockets web a través de IIS8). Creo que en 1 año más aceptaremos más MVC, ya que es de esperar que haya más controles de terceros disponibles, la tecnología se habrá asentado y tendremos la infraestructura para respaldarla.

Comentarios

• ¿Le importaría enumerar algunas de estas características que dice que requieren Windows Server 2012?

Esta decisión depende de tus preferencias, de tus requisitos o incluso de tus conocimientos y experiencia.

El tiempo de formación aprendiendo MVC o tiempo para recibir una entrega. Todas estas cosas importan para elegir uno u otro enfoque.

No es que uno sea mejor que otro, simplemente tanto el enfoque como los frameworks tienen pros y contras.

Personalmente prefiero MVC 3, Te recomiendo que pruebes y obtengas tu propia experiencia, pero debo decir que el programa en MVC es una forma limpia, divertida, flexible, extensible, segura y estructurada.

Saludos,

La única razón por la que elegiría WebForms en lugar de MVC es porque tiene muchos más controles de interfaz de usuario de terceros para WebForms que MVC. Elegí MVC porque trabajé demasiado con WebForms y quiero trabajar con algo nuevo / nuevo, pero aún de MS shop 🙂

Básicamente, nada le impide desactivar el estado de visualización en WebForms y usar ViewModels y bucles if / for en lugar del enlace de modelo y controles del lado del servidor.

¿Es este WebForms o código MVC:

<% foreach (var item in Model.Items) { %> <p><%: item.Name %></p> <% } %> 

La única limitación que encontré en WebForms es que si usa Dependency Injection / Inversion of Control, no puede tener inyección de constructor ya que las páginas de WebForms deben tener un constructor sin parámetros, por lo que debe usar la inyección de propiedad. ¿Es esto realmente tan importante?

ASP.NET MVC es realmente una respuesta a Ruby, y la nueva, moderna y (IMO) mejor forma de desacoplar el navegador (cliente) del servidor tanto como sea posible.

ASP.NET Webforms le da mucho control sobre el cliente desde el lado del servidor, con acceso directo a prácticamente todo. Básicamente, la vista y el controlador son uno en el mismo, lo que le da mucho poder y, la mayoría de las veces, mucho desorden.

ASP.NET MVC separa la vista y el controlador separando el acoplamiento estrecho de un archivo .aspx y el archivo .aspx.cs que los acompaña en los formularios web.

Básicamente, la diferencia es tener mucho más (normalmente todo) del procesamiento para mostrar datos al archivo de vista, y dejando la lógica empresarial y el resto en el controlador, manteniéndolos más limpios por convención, pero también con menos acceso entre sí de lo que permiten los formularios web.

Comentarios

• Entonces, ¿CUÁNDO deberían favorecerse los formularios web sobre MVC? Esto no responde a la pregunta de los carteles originales.
• @WeekendWarrior – Sí, cuando desee más acceso del lado del servidor al cliente, elija formularios web. Si desea más desacoplamiento del cliente / servidor en su código, elija MVC. Al final del día, ambos hacen exactamente lo mismo. Los filtros de redireccionamiento hacen lo mismo que las URL de MVC y puede mover el código de los formularios web a un nivel intermedio separado para desacoplarlo más. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Con respecto a su tercer punto, esa lógica comercial termina en el archivo .aspx.cs; creo que esto es culpa de los desarrolladores. No ‘ se supone que debe estar allí. En formularios web, el .aspx es la » vista «, el .aspx.cs es el » controller » equivalente, destinado a procesar el código que se relaciona directamente solo con la interfaz de usuario mediante el sondeo de una capa empresarial o una capa de fachada empresarial de grano grueso. El hecho de que la gente ponga lógica empresarial en .aspx.cs es simplemente una mala programación. ¡También podrían poner la lógica empresarial a la vista en MVC! MVC no ‘ t fuerza la separación de estas cosas.
• Esencialmente, tiene más razón que otras respuestas publicadas aquí. ASP.net es la idea básica detrás de una familia de tecnología web modular creada por Microsoft. El módulo MVC de ASP.net puede ser una exageración temporal, pero seguro que no es el último, todo comienza con ASP.net, así que cuándo elegir ASP.net, si no cree que MVC no es lo suyo, tal vez esté más interesado en algo. else OWIN o …, algo más avanzado, o hizo su propio marco para sus tareas. Es posible que ni siquiera necesite ASP.MVC y lo omita y vaya a Owin o Katana, pero hasta que use asp.net

En mi opinión, están lo suficientemente relacionados y tienen aproximadamente las mismas capacidades que deberían venir según sus preferencias.

Un gran desarrollador de WebForms puede producir un producto tan poderoso como un gran desarrollador MVC. Pero el gran desarrollador de WebForms que intenta forzarse a sí mismo a adoptar MVC se quedará corto. Lo mismo ocurre con un gran desarrollador de MVC que le da una oportunidad a WebForms.

No son entidades completamente separadas, y mientras Microsoft continúe soportando ambas, creo que seguirá viendo un grupo mixto de desarrolladores excepcionales para cada una.

Se trata de una elección personal, asumiendo que todos somos competentes con la tecnología que usamos. He estado usando el enfoque de diseño de WebForms durante muchos años, y debo decir que el único inconveniente es que debido a su enfoque simplista, muchas personas no se toman su tiempo para descubrir sus vastas capacidades.

Recientemente usé MVC para completar un proyecto, y aunque me gusta bastante el enfoque de diseño para el desarrollo de aplicaciones (que le da más control, URL limpias, SOC, etc.), realmente no hay mucho que proporcione , que WebForms no puede. De hecho, la aparición de jQuery y su funcionamiento con WebForms (así como con MVC) ha hecho que estos argumentos sean un problema menor. Y cuando la gente habla de la separación de preocupaciones como una ventaja que MVC tiene sobre MVP, les pregunto cuánto saben acerca de la programación orientada a objetos y cuánto ponen en uso el principio de abstracción y polimorfismo.

Actualmente me siento cómodo usando ambas tecnologías y elijo y elijo en función de la situación. Hablando francamente, depende de para usted, pero la verdad es que no todo el mundo se toma su tiempo para aprender en profundidad de lo que es capaz una tecnología en particular.

Comentarios

• Lo mismo ocurre con las vastas capacidades de los formularios web. La mayoría de las personas están viendo las ruedas de entrenamiento de los formularios web y comparando esto con MVC.
• No tiene mucho sentido aprender una abstracción sobre HTML y Javascript en esta época (incluso en 2013). No ‘ no le servirá de nada para sus futuras oportunidades. HTML y Java cript está bien tal como está. Pelear es una batalla perdida.

Cuando me enfrento a un problema de programación, a menudo busco en la web para obtener respuestas. Webforms tiene toneladas de información / componentes para hacer casi cualquier cosa. En MVC, debido a menos fuentes en línea y las capas de abstracciones necesarias para hacer que algo funcione, ha puesto un límite a las cosas que alguna vez pude hacer. MVC total mata mi productividad como desarrollador, mientras que con Webforms no lo es. Así que por ahora me quedo con los formularios web hasta que MVC haya madurado lo suficiente para reemplazarlo.

Bueno, WebForms tiene más recursos de aprendizaje disponibles (simplemente debido al hecho de que es más antiguo) y, por lo tanto, es más probable que los nuevos programadores que no están «informados» encuentren información sobre esta tecnología más antigua en contraposición a las cosas más nuevas como MVC.

Los programadores senior / experimentados son mayores y serán más competentes en la tecnología anterior debido al hecho de que han programado en ella más tiempo que tener en el más nuevo.

A menos que pueda gastar el dinero y el esfuerzo para que sus muchachos sean tan competentes en MVC como lo son en aplicaciones WebForms, sin duda va a intentar no actualizar a la nueva plataforma durante el mayor tiempo posible.

Por lo tanto, presenta varios problemas logísticos: ¿Los beneficios de MVC superan el costo en términos de menor calidad y tiempo de despliegue? Si tengo un sitio escrito completamente en WebForms, ¿valdría la pena el esfuerzo y el dinero para integrar MVC en él?

Como dijo un comentarista anterior, MVC también le impide lograr el mismo nivel de interfaz con el controlador como podría hacerlo con WebForms. Si bien estoy totalmente a favor del lado de «evitar que el usuario apriete las cosas / aprenda», todavía puede ser irrazonablemente problemático para los equipos implementar / implementar un programa que se adhiera fanáticamente a ese paradigma para todo lo que escriben.

Creo que la brecha entre estas dos tecnologías no es tan amplia como solía ser.

• Los formularios web pueden usar el motor de enrutamiento que usa MVC (o algo muy similar).
• El administrador de scripts puede combinar scripts, cargar desde una CDN e incluso retrasar la carga de scripts.

Para responder directamente a su pregunta, creo que se reduce a preferencias y / o cuál es el proyecto. Ambos adoptan un enfoque de desarrollo significativamente diferente. Personalmente, he estado trabajando para avanzar hacia MVC, pero todavía disfruto trabajando con Webforms. Creo que la respuesta a si debe usar MVC o Webforms es que usted decida experimentando ambas tecnologías.

Comentarios

• Webforms y MVC recomiendan una actitud de desarrollo web radicalmente diferente por defecto, esto es importante , pocos desarrolladores se desvían de » el » predeterminado. Sin embargo, ambos pueden usarse para lograr lo mismo.