¿Es la prueba de unidad el objetivo principal del patrón MVC?

El objetivo principal sería la "separación de preocupaciones", ya que el modelo, la vista y el controlador tienen responsabilidades distintas.

El autor del artículo original de Xerox PARC afirma que: / p>

  

El propósito esencial de MVC es cerrar la brecha entre el modelo mental del usuario humano y el modelo digital que existe en la computadora.

Si la prueba de unidad fuera el objetivo principal, uno podría realizar pruebas de unidad de forma sencilla. Una mirada al panorama de los proyectos / marcos de pruebas unitarias revelaría que es bastante contrario a lo que se afirma. Uno usualmente usaría pruebas de integración y funcionales para probar la vista.

En mi opinión, la respuesta es un firme 'no'. Quizás este fue el principal beneficio que se observó en esta organización específica, pero no lo llamaría el "objetivo principal".

Supongo que no sería tan difícil implementar MVC de alguna manera, eso es tremendamente difícil de realizar una prueba unitaria (diablos, la forma en que lo hice por primera vez fue difícilmente comprobable).

Por otro lado, se podría decir que casi cualquier patrón (excluyendo cosas como Singleton) facilita las pruebas unitarias, ya que la mayoría de las veces promueven el desacoplamiento, ¿pero es su "objetivo principal"? Apenas.

MVC (al igual que la mayoría de los patrones de diseño conocidos) estuvo presente antes de que se conocieran las pruebas unitarias. El libro de GoF se publicó en 1994, y solo documentaban los patrones que se han utilizado durante años (si no décadas) antes. (Y no hay ninguna mención de la prueba de unidad en ella). Sobre la prueba de unidad, no puedo encontrar la hora exacta en que se convirtió en "pública". Lo leí personalmente en artículos relacionados con la Programación Extrema y el primer libro de XP salió en 1999.

Obviamente, las pruebas unitarias no pueden ser el objetivo principal de inventar / documentar patrones, mientras que es justo decir que los patrones, cuando se aplican bien, facilitan enormemente las pruebas unitarias.

Creo que no, la facilidad de las pruebas unitarias es uno de los beneficios, pero es parte de una colección de beneficios cuando se usa MVC junto con las razones que enumera. Decir que hay una sola razón principal para usar MVC es un error. Suena como si la empresa en cuestión eligiera MVC para facilitar las pruebas unitarias, por lo que creen que es la razón principal. Personalmente, mis razones para usar MVC son su simplicidad en comparación con los formularios web, lo que facilita el diseño y el mantenimiento, pero cada individuo / empresa tendrá sus propias razones para usar cualquier tecnología.

En el mundo de MVC de ASP.NET, se han incluido muchas mejoras en ASP.NET en el propio marco. El propósito principal de este patrón de diseño es aislar la lógica empresarial de la interfaz del usuario para enfocarse en una mejor capacidad de mantenimiento, una mejor capacidad de prueba y una estructura más limpia para la aplicación.

ASP.NET MVC tiene ciertas capacidades que lo convierten en la mejor opción para elegir si necesita uno o más de los siguientes:

• Un alto nivel de control sobre el HTML generado : a diferencia de los formularios web, las vistas en ASP.NET MVC representan el HTML exactamente como se lo indica. Recientemente, los formularios web se han mejorado en esta área, pero aún no tienen el nivel de control que tiene MVC.

• Pruebas unitarias más sencillas : con ASP.NET MVC, es muy fácil seguir patrones de prueba como el desarrollo dirigido por pruebas (TDD). Debido al complejo ciclo de vida de los eventos en Web Forms, además de un marco basado en control, TDD es mucho más fácil con MVC.

• Separación de inquietudes : se refiere a tener todos los aspectos del sistema claramente separados unos de otros. Debido al patrón que implementa, una aplicación MVC se divide en partes discretas y poco ligadas (modelo, vistas y controladores), lo que facilita su mantenimiento.

Algunos de los otros beneficios son:

• El propio patrón MVC facilita la gestión de la complejidad al separar claramente la funcionalidad de la aplicación en tres partes principales, el modelo, la vista y el controlador.

• Las aplicaciones web ASP.NET MVC no usan el estado de vista ni los formularios basados en servidor. Esto hace que el marco MVC sea ideal para los desarrolladores que desean un control total sobre el comportamiento de una aplicación. El estado de la vista puede ser muy grande, lo cual es un problema para dispositivos como los teléfonos inteligentes que funcionan en redes lentas (la transmisión de toda esa información puede ser muy lenta). En una página de formularios web, solo puede tener uno por página. Esta es una restricción bastante importante. En MVC, no existe tal restricción, es decir, puede tener tantos elementos como desee.

• ASP.NET MVC proporciona un mejor soporte para el desarrollo guiado por pruebas (TDD).

• ASP.NET MVC funciona bien para aplicaciones web que son compatibles con grandes equipos de desarrolladores y para diseñadores web que necesitan un alto grado de control sobre el HTML. ASP.NET MVC Request Processing