MVC versus WebForms

Me parece que hay una gran cantidad de sheeping pasando, con todos subiendo al carro de MVC. Casi todos declaran que WebForms es un mal y Satanás sin mucha persuasión. Luego continúan diciendo que los controles son malos y que no deberían estar en una aplicación web. ¿Cómo vas a mostrar algo sin ningún control?

Recuerdo cuando apareció WebForms y todo el mundo los amó. Supongo que en unos años, la gente se lanzará a lo siguiente y declarará que MVC es malo porque en realidad tienes que crear controles para usar MVC y te dirán que debes desarrollar una aplicación y no preocuparte por los controles.

La forma en que lo veo MVC se puede lograr en WebForms al no incluir RunAt en la etiqueta Form. Entonces, si desea recuperar datos, simplemente use Ajax.

¿Alguien puede persuadirme sobre por qué debería usar MVC y no WebForms?

    Usted no debe decidir arbitrariamente entre uno u otro; no engordes para el framework MVC solo porque es el nuevo chico en la cuadra y todos cantan sus alabanzas, especialmente si te sientes cómodo haciendo cosas usando Web Forms. Prácticamente todos los sistemas existentes van a utilizar la tecnología más antigua y establecida, y no hay nada de malo en eso.

    Si bien es cierto que el marco MVC permite una separación aún más fácil de las preocupaciones (después de todo, para eso es el patrón MVC), también conlleva la responsabilidad de escribir más HTML, y creo que una comprensión un poco mayor de cómo funciona el trabajos web; no necesariamente un requisito irracional, pero podría argumentar que lo ralentizará un poco las primeras veces que se ponga a usarlo.

    Para ser sincero, estoy de acuerdo en que las Formas Web requieren una gran cantidad de recursos inmerecidos. Por supuesto, hay mucha magia sucediendo en segundo plano, y se tiene menos control sobre parte de la salida de HTML, pero no es exactamente imposible diseñar con CSS (es posible que acabes usando !important , tal vez), y también es no es imposible conseguir una separación de las preocupaciones, incluso si no se ajusta a la visión del purista de lo que podría ser. Todavía puede escribir código bastante horrible utilizando el marco MVC. Si estás buscando lanzar algo rápidamente, y eres bueno con Web Forms, entonces podrás lograrlo muy rápidamente, y no hay nada de lo que avergonzarse, ¿o sí?

    Eso no quiere decir, por supuesto, que debes aferrarte a tus armas e ignorar a MVC tampoco; es un buen marco (de hecho, es un marco muy bueno) y confiere varios beneficios que tal vez desee aprovechar a largo plazo. También debe recordar que tampoco anula automáticamente todo lo que aprendió sobre ASP.NET 2.0; gran parte de la architecture de soporte se incluye en el marco de MVC, incluidos elementos como los proveedores de membresía.

    En Webforms :

    Tanto Viewstate como Postbacks han tenido muchos problemas y una mayor complejidad en el desarrollo de aplicaciones web. Muchas páginas web que tienen cientos de tamaños de KB de Viewstate afectaron el rendimiento de las aplicaciones en algún momento.

    Los desarrolladores no tienen el control del HTML de representación de los formularios web y los controles del servidor que rinden html con estilo en línea mixto y tags obsoletas que no siguen los estándares.

    El ciclo de vida de la página del formulario web es demasiado complejo y tiene un acoplamiento perfecto entre todas las cosas en el marco ASP.net y una sola clase se usa tanto para mostrar el resultado como para manejar la entrada del usuario.

    Las pruebas unitarias son casi una tarea imposible. Hoy, las pruebas unitarias son muy importantes en el desarrollo de software moderno, especialmente cuando seguimos metodologías y prácticas ágiles. Debido a que la web es un evento sin estado, los eventos, los postbacks y Viewstate no son una buena manera.

    Con asp.net MVC, todas estas cosas se simplifican

    Si estas cosas no se aplican a usted y le gusta usar las formas web, entonces quédese con lo que mejor sabe hacer. No intentes arreglar algo que no esté roto.

    Para obtener más detalles, consulte: blog de Shiju de ASP.net MVC Vs ASP Web Formulario

    Veo las principales ventajas de MVC como:

    • Una architecture mucho más limpia y simple. Ya no tendrás que adivinar qué evento manejas para conectar tus datos correctamente. Ya no tendrá que insertar un gancho para “arreglar” un problema de enlace de datos porque el marco no hace exactamente lo que usted desea.
    • El marco no se sale con la suya tanto.
    • La architecture desacoplada hace mucho más fácil de probar el código.
    • Más estrechamente alineado con la architecture de la web. Para las personas que provienen de un fondo de WebForms esto puede no parecer una ventaja hasta que lo acepte y lo diseñe en lugar de intentar escribir aplicaciones similares a WebForms en MVC. Afortunadamente, había explorado Ruby on Rails antes de usar ASP.NET MVC y ya había comenzado a escribir mis aplicaciones WebForms de una manera más RESTANTE.
    • Historia / Ubicuidad: a pesar del hecho de que Microsoft acaba de implementarlo, MVC es un patrón muy conocido y muy respetado. Se usa ampliamente para muchas aplicaciones web en muchos marcos. Aprender MVC le dará una ventaja si necesita cambiar a una tecnología diferente donde también están haciendo MVC, digamos RoR o Java / Struts.

    Las desventajas:

    • La implementación de Microsoft es nueva y no tan madura.
    • Pocos “controles” / complementos de terceros para el uso de ida y vuelta: cuadrículas genéricas y demás, aunque hay muchos complementos en el lado del cliente a través de jQuery.
    • Requiere desaprender algunos paradigmas de WebForms para usarlo efectivamente.
    • El marco no hace tanto trabajo pesado para ti; Tendrás que aprender Javascript y escribir más código del lado del cliente porque el framework no se lo inyectará.

    WebForms es un gran marco, pero requiere que lo entiendas y comprendas. Y sí, aún debes ser un experto en HTML y JavaScript. Cada queja que escuché sobre WebForms proviene de alguien que no se tomó el tiempo para entender WebForms. Aquí están mis respuestas a algunos de ellos.

    ViewState is Evil y ralentizará la página

    Esto me recuerda a los progtwigdores que hicieron de todo una variable global. ¡Ciertamente puedes hacerlo, pero NO DEBERÍAS! Es lo mismo con WebForms y ViewState. No use ViewState a menos que lo necesite, y solo con moderación. No hay nada de malo en agregar 1000 caracteres de estado de vista al html, si brinda una mejor experiencia al usuario y / o acelera el tiempo de desarrollo. Puede experimentar el mismo problema en MVC al ensuciar la página con cientos de controles de entrada ocultos, y sí, lo he visto. Y por cierto, ViewState no es “mágico”, simplemente almacena algunos datos en un solo control de entrada y también lo encripta para una buena medida.

    WebForms genera html “feo” y está lleno de ID largos

    Bueno, antes que nada, nadie mira el hmtl generado (¿miraste google.com por ejemplo, es un desastre ?!). En segundo lugar, si realmente te importa generar html específico, lleva menos de una hora crear tu propio componente o control reutilizable, con el html que elijas. O puede tomar el control existente, anular el renderizado y usar ese control en su lugar. Una vez más, debe saber a dónde ir y cómo hacerlo, pero una vez que lo sepa, será un gran aumento de productividad sin ningún sacrificio. Los ID largos se generan automáticamente para garantizar la exclusividad en toda la página. Si alguna vez tiene la oportunidad de desarrollar una vista compleja de MVC, notará que va a inventar su propio patrón de identificación larga, de modo que pueda analizar los campos de formulario correctamente al publicar.

    WebForms no permite formularios múltiples por página

    He estado desarrollando durante 10 años y solo una vez necesité formularios múltiples. Y luego descubrí que no. Debe comprender las solicitudes y respuestas HTTP y cómo lograrlas con WebForms, pero si lo hace, nunca necesitará formularios múltiples, ni pensará en “formularios” en absoluto.

    Las páginas de WebForms no son verificables

    Absolutamente no es verdad Incluso si no te gusta MVP (que yo no), hay otras técnicas para probar cualquier cosa que quieras probar. Es cierto que si solo usa páginas en WebForms tal como están y pone toda la lógica en código-behid, probablemente no será comprobable y no es una buena idea. Sin embargo, al igual que en las aplicaciones MVC o Windows Forms, puede y debe, al menos para vistas complejas, crear capas intermedias, como vistas y controladores. Prefiero encapsular la funcionalidad en controles de usuario que implementan una interfaz o heredan una clase base. Entonces, la página en la que residen los controles de usuario actúa como un “controlador maestro”. Las vistas individuales, o los controles del usuario en este caso, se pueden probar porque todos implementan una interfaz o clase base.

    JavaScript es difícil de hacer en WebForms

    JavaScript es realmente más fácil de implementar en WebForms que en MVC. ¡Seguro que tienes más opciones! Pero una vez más, debes conocer bien WebForms para darte cuenta de esto. En WebForms puede “inyectar” javacript con componentes y controles reutilizables. O puede usarlo como en MVC o HTML simple después de cambiar una configuración en la página para mantener ASP implementando el esquema de nomenclatura de ID.

    Habiendo dicho todo esto, ¿qué tiene que ofrecer WebForms que MVC no tiene? La encapsulación y la reutilización de los componentes de la presentación es, con mucho, la más grande, en mi opinión. Para vistas complejas, desarrollo componentes individuales (controles de servidor o de usuario) y que un controlador personalizado o fábrica de presentación los teje todos en su lugar. Además, html en tiempo de diseño es mucho más limpio en WebForms que en MVC, por lo que el diseño y el estilo son mucho más fáciles para diseñadores gráficos formados adecuadamente. Es más limpio porque no hay código de progtwigción en tiempo de diseño html, solo marcado (no uso expresiones de enlace de datos). Y, por supuesto, la creación de prototipos es mucho más fácil en WebForms. En el caso de los prototipos, normalmente ignoro todas las mejores prácticas y recurro a los asistentes y al desagradable código subyacente que afecta directamente a la base de datos.

    Podría continuar, pero el punto principal que me gustaría hacer es que WebForms y MVC son patrones muy diferentes y requieren diferentes conjuntos de conocimientos y mentalidad para ofrecer excelentes soluciones. Ambos requieren la mayor cantidad de conocimiento de Web / HTTP / CSS que pueda obtener. Si tuviera que hacer una recomendación, generalmente, pero no siempre, para el sitio web público de alto tráfico (como blog), podría inclinarme hacia MVC. Para la aplicación web compleja, ya sea interna / intranet o membresía externa / aplicación de Internet, me inclinaría hacia WebForms.

    Los WebForms funcionan bien y, si te gustan, sigue usándolos.

    Tres de las grandes ventajas del modelo MVC como lo veo son:

    ViewState se ha ido, lo que podría crear una cantidad considerable de tráfico a través del cable. Las URL se pueden reasignar para que signifiquen algo como lo es ahora. Andamio. No sé, personalmente, creo que esto es satanás y fomenta terribles hábitos de progtwigción, pero otros parecen pensar que es una idea hermosa.

    También fomenta una separación adecuada entre la lógica empresarial y la presentación mediante la aplicación del patrón Model-View-Controller, pero un buen código WebForm también puede hacer eso.

    Entonces, realmente, si está bien con la sobrecarga de WebForms, y está de acuerdo con las URL feas y no desea el andamiaje, quédese con WebForms.

    EDITAR: Ah, sí perdí una gran ventaja de las URL “limpias”. Y la aplicación MVC es mucho más amigable para SEO. También le da un buen control sobre HTML, pero francamente, no lo considero un gran paso adelante.

    Creo que parte del problema es que muchas personas no se dan cuenta de que MVC no es una invención M $, ni es un reemplazo de formularios web. Ciertamente, a la gente le gustan las cosas “nuevas”, y a la gente le gusta tirar palabras de moda, especialmente para mejorar sus currículums …

    Finalmente, los desarrolladores de .NET tienen alguna opción, y con esa opción, se les está imponiendo cierto grado de responsabilidad por las decisiones que toman. No me sorprende que muchos desarrolladores de formularios web estén nerviosos con esta responsabilidad. No ha estado allí antes. En última instancia, puede hacerte un mejor desarrollador, o uno peor. Ahora depende de ti.

    La gente amaba los formularios web, porque era mejor que ASP (Clásico). Y sí, en 5-10 años, estoy seguro de que alguien / grupo mucho más inteligente que yo, evolucionará un nuevo paradigma / patrón.
    Tenga cuidado con la etiqueta de oveja, ya que de alguna manera, al aferrarse a un patrón específico del vendedor (formas web), usted es potencialmente una “oveja” más grande.
    MVC se encuentra ahora en una variedad de plataformas, y significa que su potencial para desarrollar soluciones significativas y estables a los problemas puede boost drásticamente. O disminuido. Depende de ti. Si no está listo, espere a que madure ASP.NET MVC. ¡Pero no cierre su mente a nada, particularmente a un patrón que está muy bien establecido!

    Recomiendo leer el blog extremadamente inflamatorio de Rob Connery. ¡Él ciertamente rasgueó mi dolor con sus dedos! Luego ve y lee cosas de RoR, Cake y Struts. ¡Todos estos comenzarán a mostrarte la visión que los chicos que trajeron MVC a .NET tienen (~ ish) y con suerte te inspirarán a ver los problemas de manera diferente!

    Hubo varias respuestas más detalladas aquí, así que en lugar de repetir todo lo que han dicho trataré de mantener mi respuesta un poco más sucinta. No debe, necesariamente, utilizar MVC sobre formularios web, del mismo modo que no debe usar formularios web sobre MVC: ambos son herramientas y son más, o menos, apropiados en diferentes situaciones. Estuve expuesto por primera vez a MVC hace unos años en J2EE, cuando recién venía .NET (no estoy seguro de que ASP.NET MVC estuviera disponible en ese momento). Proporciona un marco muy agradable y limpio y ofrece más aplicaciones “web” (es decir, solicitud / respuesta), pero también puede agregar mucha más funcionalidad del lado del cliente utilizando AJAX. He hecho algunas cosas realmente funky usando AJAX en un php. aplicación que escribí hace un tiempo y que es todo usable bajo MVC.

    Hay algunas cosas que MVC hace mejor y algunas cosas que las webforms hacen mejor, pero si no conoces ambas tecnologías no puedes elegir la mejor para el proyecto actual que estás haciendo, así que por favor no te hagas un flaco servicio – ve y aprende MVC. Incluso si nunca lo usa directamente, puede proporcionarle conocimientos útiles de “teoría” que puede aplicar en otras herramientas. Intento aprender tantas cosas diferentes como puedo, ya que cuantas más cuerdas tengo, menos probable es que no pueda resolver un problema (por ejemplo, en esa aplicación php, utilicé php, enganchado en un poco de ASP, e incluso tenía DOS y * NIX archivos de secuencia / script que realizaban ciertas funciones: cada herramienta tenía su lugar y era la más adecuada para el trabajo al que estaba asignada).

    Yo no. MVC es bastante bueno en un currículum, pero para nuestros clientes (los que pagan por nuestro trabajo), no es un impedimento para el espectáculo.

    Por lo general, desean aplicaciones correctas, rápidas y seguras. Eso es todo. ¡No querrán cambiar la tercera capa de la parte del cliente en tres años! En tres años, cambiarán todo o nada en absoluto.

    Las capas son divertidas de diseñar y codificar, pero cuestan mucho crearlas y mantenerlas, y no son relevantes para nuestros clientes. MVC es genial, pero realmente inútil y costoso.

    A menos que, por supuesto, esté desarrollando aplicaciones para 4 sistemas operativos y 3 plataformas … Pero entonces será una minoría.

    : o)

    Esta es una discusión estúpida: ¡son diferentes , ASP.NET MVC y WebForms son tecnologías diferentes! Estoy usando MVC para todos los proyectos nuevos, pero cuando me enfrento a una necesidad de RAD uso WinForms, porque es simple y hay muchos controles ya escritos por los gurús.

    Deja de discutir esto. ¿Quién quiere entender la diferencia? Solo prueba ambas tecnologías y lo entenderás por ti mismo.