¿Por qué usaría MVC sobre formularios web?

Recientemente, un arquitecto describió a nuestra empresa como una solución Rolls-Royce (MVC) cuando todo lo que necesitaba era un Toyota (formularios web).

Tengo curiosidad por saber qué piensa sobre los formularios web vs MVC como una opción arquitectónica.

La analogía Rolls-Royce / Toyota es terriblemente defectuosa y engañosa. Uno (ASP.NET MVC) no es simplemente una versión más elegante o más cara del otro (ASP.NET WebForms). Son enfoques muy diferentes para construir aplicaciones web usando ASP.NET.

Para mí, la mayor diferencia arquitectónica entre MVC y WebForms es cómo funcionan con el entorno sin estado de la web: WebForms trabaja duro para construir un conjunto de abstracciones que ocultan la naturaleza sin estado de la programación web, mientras que MVC adopta el entorno sin estado y trabaja con eso.

Cada enfoque tiene sus beneficios y perjuicios, pero realmente disfruto cómo la construcción de sitios web con MVC se siente mucho más natural que WebForms (con su capa tras capa de abstracciones con fugas ).

Antigua pregunta, pero merece una respuesta más detallada en caso de que alguien más todavía tenga un dilema al respecto.

En última instancia, los formularios web son una solución de cliente ligero por lo que significa que presionas un montón de botones bonitos y las cosas de front-end (cliente) están diseñadas para ti. Si tiene personas que saben cómo ponerlo en marcha en los formularios web y no hay absolutamente ninguna preocupación de mantenimiento / modificabilidad y el sitio es completamente a corto plazo y desechable, no hay nada de malo en este enfoque. Es posible aprender a hacer sus propias cosas, pero en este caso requeriría saber que tanto los formularios web de material web intentan proteger a los desarrolladores de aplicaciones .NET como todos los elementos de formularios web que hacen que la mayoría de los desarrolladores web del lado del cliente quieran asesinar a Microsoft ingenieros responsables

En el 99.5% de todos los demás escenarios de casos de uso, hemos dejado de tratar de ocultar la web a los desarrolladores de aplicaciones porque realmente, si desea escribir aplicaciones web, es mucho mejor aprender realmente cómo funciona la web. La ironía de las soluciones de cliente grueso frente a cliente ligero es que, inevitablemente, el enfoque de cliente ligero hincha inevitablemente su extremo frontal y es todo menos eficaz. Más importante aún, estas soluciones siempre han hecho que las cosas sean inflexibles como un infierno para las personas que realmente saben lo que están haciendo y no quieren verse limitadas por el marco vigente.

No hay nada tan inútil como tomar a alguien que sabe todo sobre CSS, JavaScript, HTML, XHR y hacerlos completamente inútiles al bloquearlos en cada paso del camino con un marco que ...

• Borra todas las etiquetas de script 'innecesarias' en las etiquetas de encabezado para evitar que arruines las dependencias de script. (mejor dejar que un 'administrador de guiones' se encargue de eso por usted) De acuerdo, nadie los pone allí hoy si saben lo que están haciendo, pero eso es un desastre.

• Insiste en que envuelva todo el HTML en una etiqueta de formulario descomunal. HTML no permite formularios dentro de los formularios, por lo que los formularios se hacen de forma web o de ninguna manera.

• Crea como un "ciclo de vida" de 18 pasos para lo que realmente debería reducirse a reaccionar a los eventos de la interfaz de usuario al interactuar con el navegador para enviar mensajes al servidor y luego reaccionar cuando el servidor responde. Nunca fue necesario abstraer ese proceso con una gran pila gigante de basura (y para ser justos, MS no es el único imbécil que ha intentado hacer esto).

• Realmente hace todo lo posible para interponerse en el uso de soluciones de problemas que no son de formularios web. Ejemplo: cuando era un desarrollador más joven del lado del cliente, pasé un día entero buscando la manera de hacer que un botón de envío en la parte superior de la página activara un botón de envío en la parte inferior de una página (supongo que debido a ese gran tamaño) cosa de forma gigante). Normalmente, esto llevaría 5 minutos, pero después de varias horas de ingeniería inversa de los formularios web responsables de JavaScript, descubrí que estaban, entre otras cosas, configurando una propiedad que ni siquiera sabía en ese momento que le indica cuál es el último elemento de formulario que debe tener el enfoque era que cuando se hacía clic en un botón de envío, solo el botón oficial de envío de Microsoft (tm) funcionaría con respecto a la activación de un controlador oficial de envío de Microsoft (tm).

Entonces no, Rolls-Royce vs Toyota, es completamente irracional. Yo diría más, un Hyundai perfectamente razonable por el que pagas demasiado frente a un Pinto diseñado por Microsoft con un sistema integrado que automáticamente realiza giros bruscos de 90 grados cuando descubre que compraste gas o petróleo a alguien que no sea Microsoft y se detecta un conveniente pared para golpear. Un automóvil ideal para el conductor leal de marca suicida que no sabe nada sobre la web y quiere jurar lealtad de por vida a Microsoft.

Todo lo que .NET MVC realmente es, es simple y razonable, y no reinventa su propia capa para abofetear a la web. Simplemente funciona con lo que hay allí para ayudar a eliminar algunas repeticiones para usted. Hay marcos mejores / más baratos / libres disponibles, pero si ya te has encerrado en lo de .NET, podrías hacerlo mucho peor.

Pero en serio, manténgase alejado de los formularios web @. Está casi muerto ahora. Déjalo ir. Dígale a sus clientes que lo hará por tres veces más dinero si también le prometen un contrato de soporte por horas exclusivo y lucrativo para cuando realmente quieran hacer algo nuevo o diferente o cuando la basura comience a romperse porque ni siquiera la EM se molestará en continuar agregando a ese gigante de un archivo ajax.js de 10,000 líneas que sacan de su culo DLL donde no puede tocarlo.

Una solución ASP.NET MVC no tiene que ser más complicada que una solución WebForms. Personalmente, creo que ASP.NET MVC en realidad es mucho más simple que WebForms, y definitivamente parece ser inherentemente más limpio.

Según mi experiencia, muchos de los marcos MVC (ASP.NET, Rails, CodeIgniter, etc.) tienen la misma funcionalidad y convenciones centrales. WebForms es realmente el pato extraño desde una perspectiva web. Supongo que la mayoría de los programadores web serían mucho más rápidos al elegir ASP.NET MVC que WebForms.

La razón principal por la que usaría ASP.NET MVC sobre ASP.NET WebForms es la capacidad de prueba. Claro que puede hacer pruebas unitarias de WebForms, pero esto requiere marcos de trabajo burlones y mucho dolor. La segunda razón es que MVC hace que sea un poco más fácil separar las preocupaciones. Esto puede proporcionar una gran cantidad de reutilización de código y hacer que su código se acople libremente. Esto no significa que sea imposible hacer lo mismo en ASP.NET con patrones como MVP.

La desventaja de MVC es que pierde mucha funcionalidad y eso se ha incorporado a WebForms durante la última década (bueno, casi). MVC ha recorrido un largo camino desde su inicio para proporcionar características similares.

En cuanto al rendimiento, ¿alguien tiene pruebas de una forma u otra de que la tecnología es "más rápida"?

No creo que uno sea mejor que el otro. Realmente me gusta el marco MVC y lo he usado con gran éxito, pero siempre me aseguro de elegir la tecnología que coincida con el proyecto.