asp.net mvc - ventajas - Thunderdome MVC: ¿Por qué un modelo en MVC?
mvc ejemplos (3)
Cuando Jeremy y Chad publicaron sobre su proyecto FubuMvc , uno de los diferenciadores que mencionaron fue su "Director Thunderdome":
El "Principio de Thunderdome": todos los métodos de controlador toman un objeto ViewModel (o cero objetos en algunos casos) y devuelven un único objeto ViewModel (un objeto entra, un objeto sale). Las clases de Controller NUNCA se expondrán directamente a nada relacionado con HttpContext. Nada me hace llorar como ver a personas tratando de escribir pruebas que simulan o resisten la nueva interfaz IHttpContextWrapper. Del mismo modo, los métodos de controlador no devuelven objetos ViewResult y generalmente están desacoplados de toda la infraestructura de MVC. Adoptamos esta estrategia muy temprano como una forma de hacer que las pruebas de los Controladores sean más simples mecánicamente. Definitivamente se ha logrado ese objetivo, pero también ha hecho que el código del controlador sea muy sencillo y fácil de leer. Explicaremos cómo funciona esto en KaizenConf.
¿Cuál es la ventaja de su enfoque ''one ViewModel (o cero) in'' ?
La ventaja es que no depende de ningún tipo de contexto (como el estado de la sesión, por ejemplo) desde fuera de los métodos del controlador. Eso hace que sea más fácil probarlos, ya que no tiene que "simular" ese contexto mediante el uso de simulaciones, sino que también lo hace menos práctico ya que tiene que pasar todo por parámetros.
El beneficio del principio de thunderdome es que simplifica los controladores. Debido a que el trabajo de asignar valores http a objetos se realiza fuera de los controladores, significa que los controladores solo hacen lo que deberían.
Su principal beneficio es que es una convención y hace que las cosas sean consistentes en todos nuestros controladores. Nos facilita la configuración de "contextos" / dispositivos de prueba que pueden inicializar el entorno en un escenario de prueba de integración. En la mayoría de los casos, Conventions == Rapidity, ya que elimina una gran cantidad de escenarios "what if" de sus consideraciones de diseño.
Dado que todas nuestras acciones de controlador siguen el mismo patrón, podemos asumir muchas cosas y esto acelera y optimiza nuestros esfuerzos de prueba integrados de controlador.
No hay nada de malo, necesariamente, en tener múltiples argumentos para una acción de controlador, pero descubrimos que tener un objeto de modelo real nos brinda alguna funcionalidad adicional ya que el modelo puede contener una lógica simple y exponer propiedades de conveniencia que pueden simplemente algunos de los aspectos más complejos de su propio estado, etc. básicamente, este es el argumento para tener cualquier modelo rico y no es exclusivo del patrón Thunderdome / OMIOMO.