Cuándo favorecer ASP.NET WebForms sobre MVC

Sé que Microsoft ha dicho

ASP.NET MVC no es un reemplazo para WebForms.

Y algunos desarrolladores dicen que WebForms es más rápido para desarrollar que MVC. Pero creo que la velocidad de codificación se reduce al nivel de comodidad con la tecnología, por lo que no quiero ninguna respuesta en ese sentido.

Dado que ASP.NET MVC le da al desarrollador más control sobre su aplicación, ¿por qué WebForms no se considera obsoleto? Alternativamente, ¿cuándo debería favorecer WebForms sobre MVC para un nuevo desarrollo?

Webforms vs. MVC parece ser un tema candente en este momento. Todos los que conozco anuncian que MVC será la próxima gran cosa. Por mis pequeñas modificaciones, parece estar bien, pero no, no creo que sea el final de los formularios web.

Mi razonamiento, y el razonamiento de por qué se elegirían los formularios web en lugar de MVC, tiene más que ver con una perspectiva comercial que con lo que uno es mejor que el otro.

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

Si la mayoría de su equipo conoce los formularios web y no tiene tiempo para actualizarlos 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 debes hacer son cosas muy diferentes. La curva de aprendizaje es alta, por lo que debe incluir eso en su presupuesto.

Si tiene un sitio web grande escrito en formularios web, es probable que esté más dispuesto a crear páginas nuevas en formularios web para que no tenga dos tipos muy diferentes de páginas en su sitio.

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

Mi compañía recientemente hizo tres páginas de prueba con MVC. Nos sentamos y los diseñamos. Un problema con el que nos 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 grande, 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 de MVC pudieran usar la misma página maestra para una apariencia común. Ahora tenemos una capa adicional de anidamiento.

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 de esto, no será mejor que los formularios web que tiene ahora. Peor aún, incluso podría estar configurando esta tecnología para el fracaso en su empresa si está en mal estado, ya que la alta gerencia podría verla como algo inferior a lo que saben.

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

• La página lifecylce es más simple y más eficiente.
• No existen los controles además de los controles html. No necesita depurar su salida para ver qué ASP .Net está generando.
• ViewModels le brinda un poder inmenso y evita la necesidad de realizar un enlace de control manual y elimina muchos errores relacionados con el enlace.
• Puede tener múltiples formularios en una página. Esta fue una limitación seria de WebForms.
• La web no tiene estado y MVC coincide más con la arquitectura de la web. Webforms presenta el estado y los errores que tiene con él al presentar ViewState. ViewState es automático y funciona en segundo plano, por lo que no siempre se comporta de la manera deseada.
• Las aplicaciones web necesitan trabajar con ajax en estos días. Ya no es aceptable tener cargas de página completa. MVC hace que ajax sea mucho mejor, más fácil y más eficiente con JQuery.
• Debido a que puede tener múltiples formularios en una página, y debido a que la arquitectura está impulsada por llamadas a URL, puede hacer cosas extravagantes como ajax cargar un formulario diferente, como un formulario de edición en su página actual usando JQuery. Una vez que te das cuenta de lo que esto te permite hacer, puedes hacer cosas increíbles fácilmente.
• ASP .Net WebForms no es solo una abstracción sobre html, es extremadamente compleja. A veces, obtienes un error extraño y luchas con él durante mucho más tiempo del necesario. En muchos casos, podría ver lo que estaba haciendo mal, pero no puede hacer nada al respecto. Terminas haciendo soluciones extrañas.
• WebForms no es una buena tecnología para diseñadores. A los diseñadores a menudo les gusta trabajar directamente con html. En MVC es una vista, en WebForms es medio día de trabajo.
• A medida que la plataforma web evoluciona rápidamente, WebForms no se mantendrá al día. No tiene conocimiento de nuevas etiquetas o características de HTML5, seguirá presentando las mismas cosas a menos que obtenga (a menudo) controles de terceros caros 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 WebForms evoluciona, pero esa fue mi experiencia original. En general, me resultaría extremadamente difícil encontrar un caso de negocio para WebForms a menos que un proyecto ya lo esté utilizando.

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

"Diferentes clientes buscan diferentes enfoques de programación, y a muchos les encantan los WebForms y piensan que es genial. Otros aman MVC y piensan 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 "problema blando", 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.

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 convenciones de programación modernas y patrones adoptados por la industria para la plataforma ASP.NET. En el lado negativo, se espera que sepa cómo funcionan los recursos HTML y del lado del cliente (Javascript, CSS), así como el aumento de la mentalidad de programación MVC que tiene una curva de aprendizaje empinada pero que llega a un final repentino una vez que se comprende.
• Utilice ASP.NET Web Forms si está utilizando o desea utilizar un enfoque GUI- centrado, RAD (Desarrollo rápido de aplicaciones) , de arrastrar y soltar para crear prototipos de algo muy rápidamente, es decir, el comportamiento de la rejilla de datos / botón pulsador conectado dentro 15 minutos, y la solución no pretende ser algo compatible con los desarrolladores. O bien, use los formularios web ASP.NET si tiene experiencia en desarrollo de GUI o formularios Windows Forms y desea transferir su conocimiento a la web.

Pero para ver esto correctamente, debes entender la historia de cada uno.

ASP.NET Web Forms fue la respuesta de Microsoft a aquellos que habían estado creando aplicaciones web dinámicas utilizando controles ActiveX de Visual Basic 6, 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 del .NET Framework, que fue el resultado de que Microsoft esencialmente volviera a la mesa de dibujo sobre cómo hacer una programación empresarial productiva en la pila de Windows, ASP.NET Web Forms fue, en su día, increíble y hermoso.

Todo el enfoque consistía en brindar 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" VB6 / WinForms (una ventana), una página web es un formulario (como una ventana, ver) , y en ese formulario puede arrastrar y soltar etiquetas, cuadros de texto, cuadrículas de datos, botones y otras cosas a las que los desarrolladores de VB / WinForms GUI estaban acostumbrados.

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 estará en el editor de código, diciéndole al formulario qué hacer cuando ocurra ese evento de "clic". Así fue exactamente cómo los desarrolladores de la GUI de Windows crearon software utilizando las herramientas de la GUI de VB6 y herramientas de la competencia, ¡ excepto que ahora el código se está ejecutando en el servidor! ¡Guauu!

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

Desafortunadamente, este modelo de programación enfatiza tanto la metáfora de la programación de la GUI de Windows que conlleva la carga de los detalles de implementación necesarios, todo el equipaje necesario para acomodar los ciclos de vida del evento y la ocultación de los detalles feos del HTML simple y script que generarían estos componentes y controles de arrastrar y soltar. Y al final del día, los desarrolladores que soportan aplicaciones reales inevitablemente tuvieron que profundizar en estos componentes o escribir los suyos propios, y en consecuencia pelearían batallas con esta infraestructura, batallas que dejarían montones sobre montones de baldosas, cabello recogido y lágrimas.

Apoyo. Lava tus manos. Echemos un vistazo al problema comercial nuevamente. ¿Cuáles son nuestros objetivos comerciales?

Necesitamos construir y administrar aplicaciones web . Nuestras limitaciones son que tenemos la World Wide Web, que se encuentra 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 centrarnos en los problemas de la aplicación y eliminar las metáforas de la GUI?

Aquí es donde entra en juego ASP.NET MVC. Comenzó con una rebelión de desarrolladores que se autodenominaban "Alt.Net" y querían volver a los principios de desarrollo de software adecuados y puros. No más complicaciones y problemas, solo enfóquese 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 debe ver el marcado con los detalles de configuración de la conexión de la base de datos, y de esta manera un desarrollador puede centrarse 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 del HTML y los recursos relacionados . En Web Forms, el HTML está escondido, se desalienta a los desarrolladores a que se preocupen por eso. En ASP.NET MVC, se alienta a los desarrolladores a administrar 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 él en lugar de hacerlo en contra.
3. Testabilidad de los objetos comerciales . Los controladores y modelos son mucho más adecuados para las pruebas unitarias programáticas, de modo que las implementaciones pueden validarse para cumplir con los objetivos comerciales, y los cambios pueden verificarse para que no se rompan. Con Web Forms fue difícil probarlo ya que los componentes no fueron diseñados para ser probados individualmente y todo el resultado del desarrollo giró en torno a los formularios de página y sus ciclos de vida de eventos con la lógica comercial 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 es un lenguaje de programación de alto nivel. Toda la historia habría sido diferente si estuviéramos tratando con lenguaje ensamblador y C.

Luego, ampliando el n. ° 2, otro objetivo de ASP.NET MVC es permitir a los desarrolladores organizar los detalles de la parte 'vista' de sus soluciones y aprovechar la rica base sobre la que el resto de la industria ha construido La plataforma de cliente front-end.

Descubrirá que los desarrolladores de ASP.NET MVC se sienten como en casa utilizando bibliotecas Javascript ricas y técnicas de plantillas del lado del cliente sin luchar con la arquitectura del lado del servidor. Este no fue originalmente el caso con los formularios web ASP.NET, porque los formularios web no quieren que usted vea el HTML o el script en absoluto, excepto si realmente tiene que hacerlo , en cuyo caso, tenga cuidado, no es para los débiles de corazón.

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

WebForms
Úselos cuando tenga que hacer un trabajo pesado serio con las redes. Los controles de cuadrícula son realmente muy agradables cuando tiene un conjunto de datos simple que se adapta muy bien en un formato tabular y desea proporcionar una manera simple para que los usuarios actualicen los registros. Sí, sé que MVC 4 tiene un tipo de lista de Ajax realmente elegante que puedes usar que funciona muy bien, pero, en nuestro negocio, a menudo necesitamos poner en funcionamiento algo ayer y las buenas cuadrículas anticuadas funcionan muy bien y los usuarios están felices de ser capaz de atravesar una cuadrícula con alegría. Para mí, eso es lo mejor de WebForms para mí; pero como Ryanseñaló WebForms puede ser un gran desastre porque estás jugando a ambos lados de la cerca desde un ingenioso archivo de código subyacente. Puede ser una rosa y una espina al mismo tiempo para mantener todas sus cosas del tipo de controlador entremezcladas con su (s) vista (s).

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 mantenibilidad superan el costo de configuración inicial. Si desea hacer interacciones interesantes con Ajax, prefiera escribir su modelo con código, como limpiar url y rutas, y poder controlar todo el flujo de su aplicación, este es definitivamente el camino a seguir. Al principio lleva un tiempo acostumbrarse, pero creo que es la mejor opción para las aplicaciones nuevas.

En conclusión, para mí, todo se reduce a grillas y grillas. :)

Mi experiencia:

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

Después de esa experiencia, intenté escribir otra aplicación usando formularios web y me sentí frustrado 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é con MVC, y al tener un control más directo sobre la salida (y algo de experiencia con el paradigma MVC de CakePHP) pude completar esa aplicación simple exactamente como la quería en aproximadamente 1/2 día.

La disponibilidad de marcos de interfaz de usuario potentes como jQuery elimina en gran medida el atractivo de renunciar al control directo de la salida a favor del uso de componentes de interfaz de usuario preconstruidos a menudo voluminosos.

Prefiero 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 arregle de la noche a la mañana con los formularios, también, si tengo un problema de velocidad en una página, un libro muy bueno sobre la velocidad de asp.net es útil (Rick Kiessig es el hombre).

webforms es para ex windows people mvc es para web people

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

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

Creo que abstraer REST básico es malo, todo el modelo de devolución de datos es malo, 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 es malo, las URL son malos.

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 presente o no había oído hablar de eso. 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 me ayudaron mucho (muchísimo, me facilitaron la vida) .

Ahora, después de todo ese tiempo, no estaba trabajando en ningún proyecto web hasta hace poco y simplemente construía alguna 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 de esto en todas partes, además de que yo también necesitaba aprender, así que elegí MVC). El proyecto todavía está en fase de desarrollo, ya que todavía estoy aprendiendo y construyendo juntos.

Entonces, las diferencias clave que encuentro b / w son las siguientes: -

• Para alguien que viene del desarrollo de Windows, los formularios web siempre serán favorables. La curva de aprendizaje de Asp.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 lo último de todos.

• 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 uno solo necesitaba copiar y pegar. Pero, esto requiere que se hagan algunas cosas.

En resumen, ambos se quedará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 considerarla.

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 Web Forms entregue una interfaz en el mismo conjunto de datos que un Win Forms existente (o desarrollado simultáneamente) o Proyecto WPF. Hacerlo permite a los desarrolladores cruzar 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 contrapartes de Microsoft; así que, naturalmente, la elección de MVC puede verse influenciada por la experiencia del equipo en esas áreas, junto con los factores presentados en otras respuestas.

Nuestra razón para no ir a MVC hace unos años fue que 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 funcionado a dónde van con esto. Sin embargo, todavía somos reacios a desarrollar las principales aplicaciones de LOB usando MVC ya que las características que queremos usar en la versión 4 requieren un servidor Windows 2012 (re sockets web a través de IIS8). Creo que en 1 año más aceptaremos más MVC ya que esperamos que haya más controles de terceros disponibles, la tecnología se habrá asentado y tendremos la infraestructura para respaldarla.

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

El tiempo de capacitación para aprender MVC o el tiempo para recibir un parto. Todas estas cosas son importantes para elegir uno u otro enfoque.

No es que uno sea mejor que otro, simplemente tanto el enfoque como los marcos tienen ventajas y desventajas.

Personalmente, estoy a favor de MVC 3, te recomiendo que pruebes y adquieras tu propia experiencia, pero debo decir que el programa en MVC es una forma limpia, divertida, flexible, ampliable, 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 UI de terceros para WebForms que MVC. Elijo MVC porque trabajé demasiado con WebForms y quiero trabajar con algo nuevo / nuevo, pero aún de MS shop :)

Básicamente, nada le impide apagar el estado de vista en WebForms y usar ViewModels y bucles if / for en lugar de los enlaces del modelo y los controles del lado del servidor.

¿Es esto 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 Inyección de dependencia / Inversión de 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 un gran problema?

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

ASP.NET Webforms le brinda mucho control sobre el cliente desde el lado del servidor, con acceso directo a casi todo. Esencialmente, su vista y controlador son uno en el mismo, lo que le da mucha potencia y, en la mayoría de los casos, un montón de 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.

Esencialmente, la diferencia es tener mucho más (generalmente todo) del procesamiento para mostrar datos en el archivo de vista, y dejar la lógica de negocios y el resto en el controlador, manteniéndolos a ambos más limpios por convención, pero también con menos acceso a cada uno aparte de los formularios web permite.

En mi opinión, están lo suficientemente relacionados y tienen aproximadamente las mismas capacidades que debería reducirse a la preferencia.

Un gran desarrollador de WebForms puede producir un producto igualmente poderoso que un gran desarrollador de 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 dando soporte a ambas, creo que continuará viendo un grupo mixto de desarrolladores excepcionales para cada una.

Esto se trata de elección personal, suponiendo que todos somos competentes con la tecnología que utilizamos. 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 utilicé MVC para completar un proyecto, y aunque me gusta bastante el enfoque de diseño para el desarrollo de aplicaciones (que le brinda más control, URL limpias, SOC, etc.), realmente no hay mucho que brinde, que WebForms no puede. De hecho, la aparición de jQuery y su funcionamiento con WebForms (así como MVC) ha hecho que estos argumentos sean menos problemáticos. Y cuando la gente habla de la separación de preocupaciones como una ventaja que MVC tiene sobre MVP, les pregunto cuánto saben sobre la programación orientada a objetos y cuánto ponen en práctica el principio de abstracción y polimorfismo.

Actualmente me siento cómodo usando ambas tecnologías y elijo y elijo según la situación. Francamente, depende de usted, pero la verdad es que no todos se toman su tiempo para aprender en profundidad de qué es capaz una tecnología en particular.

Cuando me enfrento a un problema de programación, a menudo busco respuestas en la web. Webforms tiene toneladas de información / componentes para hacer casi cualquier cosa. En MVC debido a la menor cantidad de fuentes en línea y las capas de abstracciones necesarias para que algo funcione, ha puesto un límite en las cosas que una vez pude hacer. MVC total mata mi productividad como desarrollador, mientras que con Webforms no lo es. Entonces, 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, los nuevos programadores que no están "informados" tendrán más probabilidades de encontrar información sobre esta tecnología más antigua en comparación con las 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 en la nueva.

A menos que pueda gastar el dinero y el esfuerzo para lograr que sus muchachos sean tan competentes en MVC como lo son en las aplicaciones de WebForms, sin duda intentará retrasar la actualización 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 implementación? Si tengo un sitio escrito completamente en WebForms, ¿valdría la pena el esfuerzo y el dinero para integrar MVC en él?

Como lo indicó un comentarista anterior, MVC también le impide alcanzar el mismo nivel de interfaz con el controlador que lo haría con WebForms. Si bien estoy a favor de "Evitar que el usuario rellene / aprenda cosas", todavía puede ser excesivamente problemático para los equipos implementar / implementar un programa que se apegue 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 guiones puede combinar guiones, cargar desde una CDN e incluso retrasar la carga de guiones.

Para responder directamente a su pregunta, creo que se trata de 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 aún así disfruto trabajar con formularios web. Creo que la respuesta a si debe usar MVC o Webforms es que usted decida a través de la experiencia de ambas tecnologías.