¿Por qué usarías MVC en formularios web?

Question

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

Tengo curiosidad por descubrir qué piensa sobre las formularios web frente a MVC como una elección arquitectónica.

Answer 1

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 crear aplicaciones web utilizando 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 abarca el entorno sin estado y funciona con eso.

Cada enfoque tiene sus beneficios y detrimentos, pero realmente disfruto cómo construir sitios web con MVC se siente mucho más natural que las formas web (con su capa sobre capa de abstracciones con fugas).

Answer 2

Pregunta antigua, pero merece una respuesta más detallada en caso de que alguien más todavía tenga un dilema sobre ella.

En última instancia, WebForms es una solución de cliente delgado por la cual se entiende que presiona un montón de botones bonitos y las cosas frontales (cliente) están construidas para usted. Si tiene personas que saben cómo producirlo en las formas web y no hay absolutamente ninguna preocupación de mantenimiento/modificabilidad y el sitio es completamente a corto plazo y desechable, no hay nada malo en este enfoque. Es posible aprender a hacer sus propias cosas, pero en este caso requeriría saber que las formas web de cosas web intenta proteger a los desarrolladores de aplicaciones de .NET y todas las cosas de las formas web que hace que la mayoría de los desarrolladores web del lado del cliente quieran asesinar al Microsoft ingenieros responsables.

En el 99.5% de todos los demás escenarios de casos de uso, hemos dejado de intentar ocultar la web a los desarrolladores de aplicaciones porque realmente, si desea escribir aplicaciones web, es mucho mejor, realmente aprendiendo cómo funciona la web. La ironía de las gruesas soluciones de clientes delgadas es que inevitablemente el enfoque del cable delgado inevitablemente hincha la basura de su parte delantera y es todo menos rentable. Más importante aún, estas soluciones siempre han hecho las cosas inflexibles como el infierno para las personas que realmente saben lo que están haciendo y no quieren ser limitadas por el marco vigente.

No hay nada tan inútil como tomar a alguien que sepa 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 la cabeza para evitar que arruine las dependencias de scripts. (Es mejor dejar que un 'gerente de script' maneje eso para usted) Concedido, nadie los pone allí hoy en día si saben lo que están haciendo, pero eso es simplemente desordenado.

• Insiste en que envuelva todo el HTML en una etiqueta de forma ginmous. HTML no permite formularios internos para que realice formularios de forma web o de ninguna manera.

• Crea un "ciclo de vida" de 18 pasos para lo que realmente debería reducirse a reaccionar a los eventos de la interfaz de usuario interactuando con el navegador para enviar mensajes al servidor y luego reaccionar cuando el servidor responde. Abrazar ese proceso con una gran pila de basura gigante nunca tuvo que suceder (y para ser justos, la Sra. No es la única imbécil que ha tratado de hacer esto).

• En realidad, hace todo lo posible para interponerse en el uso de soluciones no Webforms a los problemas. Ejemplo: cuando era un desarrollador del lado del cliente más junior, pasé un día entero encontrando una manera de hacer un botón de envío en la parte superior de la página activador un botón de envío en la parte inferior de una página (supongo que debido a ese big- cosa de forma gigante). Normalmente, esto tomaría 5 minutos, pero después de bastantes horas de ingeniería inversa de la Ingeniería WebForms JavaScript responsable, descubrí que estaban, entre otras cosas, estableciendo una propiedad que ni siquiera conocía en ese momento que le dice cuál es el último elemento de formulario que tiene El enfoque fue para que cuando se hizo clic en un botón de envío, solo el botón Oficial Microsoft Envir (TM) funcionaría con respecto a la activación de un controlador de envío oficial de Microsoft (TM).

Así que no, Rolls-Royce vs Toyota, es completamente irrazonable. Diría más, un Hyundai perfectamente razonable que pagas demasiado por frente a un pinto diseñado por Microsoft con un sistema a bordo que realiza automáticamente giros de 90 grados cuando descubre que compró gas o aceite de alguien que no sea Microsoft y se detectó un Muro conveniente para golpear. Un automóvil ideal para el conductor de la marca suicida que no sabe nada sobre la web y quiere jurar lealtad de toda la vida a Microsoft.

Todo .NET MVC realmente es simple y razonable, y no reinventa su propia capa para abofetear en la web. Simplemente funciona con lo que hay para ayudarlo a noquear un bourplate para usted. Hay marcos mejores/más baratos/Free-ER disponibles, pero si ya se ha encerrado en la cosa .NET, podría hacerlo mucho peor.

Pero en serio, mantente el!@#$ Lejos de las formas web. Ahora está casi muerto. Déjalo ir. Dígale a sus clientes que lo hará por tres veces el dinero si también le prometen un contrato de apoyo exclusivo y lucrativo por la hora para cuando realmente quieran hacer algo nuevo o diferente o cuando la basura comienza a romperse porque ni siquiera podría MS podría molestarme en continuar agregando a ese gigante de un archivo de 10,000 línea Ajax.js que sacan de su culo DLL donde no puede tocarlo.

Answer 3

Una solución ASP.NET MVC no tiene que ser más complicada que una solución de Forms. Personalmente, encuentro que ASP.NET MVC es mucho más simple que las formas web, y definitivamente parece ser inherentemente más limpio.

Desde mi experiencia, muchos de los marcos MVC (ASP.NET, Rails, CodeInigner, etc.) tienen gran parte de la misma funcionalidad y convenciones básicas. 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 recoger ASP.NET MVC que las Formas web.

Answer 4

La razón principal por la que usaría ASP.NET MVC sobre ASP.NET WebForms es Testability. Seguro que puede probar las formas web de prueba unitaria, pero esto requiere burlones de burla y mucho dolor. La segunda razón es que MVC lo hace un poco más fácil para 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 que se ha incorporado en las formas web en la última década (bueno). MVC ha recorrido un largo camino desde su inicio de proporcionar características similares.

En cuanto al rendimiento, ¿alguien tiene pruebas de una forma u otra de la cual 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.