DRY vs Seguridad y Mantenibilidad con modelos MVC y View

Question

Me gusta esforzarme por DRY, y obviamente no siempre es posible. Sin embargo, tengo que rascarme la cabeza con un concepto que parece bastante común en MVC, el del "Modelo de Vista".

El modelo de vista está diseñado para pasar solo la cantidad mínima de información a la vista, por cuestiones de seguridad, mantenimiento y prueba. Lo entiendo. Que tiene sentido.

Sin embargo, desde una perspectiva DRY, un modelo de vista simplemente duplica los datos que ya tiene. El modelo de vista puede ser temporal y usarse solo como DTO, pero básicamente está manteniendo dos versiones diferentes del mismo modelo que parece violar el principal DRY.

¿Los modelos de Do View violan DRY? ¿Son ellos un mal necesario? ¿Hacen más bien que mal?

Answer 1

Esto ha aparecido una y otra vez. No solo es un engaño bastante importante, sino que la respuesta es subjetiva y argumentativa. ViewModels es una respuesta a DDD y al concepto de ignorancia de persistencia.

Decir que no usar ViewModels es malo significa ignorar que Django and Rails y la mayoría de los frameworks PHP ORM/MVC no se preocupan en absoluto por esos conceptos. ¿Quieres que alguien te diga que todos esos otros lenguajes y marcos están "haciéndolo mal?".

Si usted quiere usar ViewModels es 100% dependiente de qué estilos de arquitectura está buscando y cuáles son los objetivos de la aplicación.

Esto es como preguntar ¿es necesario arrastrar y soltar GridViews en una aplicación WebForm? Depende de muchas cosas.

También existe un concepto erróneo acerca de DRY que tiene aquí. ¿Las clases Proxy de un servicio WCF violan DRY? ¿El ViewModel contiene lógica? El objetivo principal de DRY es no tener una lógica duplicada con un propósito significativo. ¿Violar eso un par de DTO que comparten shapres de objeto?

El principal de DDD de contextos delimitados también sería una buena lectura. Si un objeto ShoppingCart necesita funcionar de manera diferente en un almacén frente a la configuración del sitio web de comercio electrónico, ¿eso significa que debe compartir los tipos? ¿Qué sucede cuando la única funcionalidad compartida es un precio total (precio + impuesto + envío)? ¿Creas una clase base solo para eso, por lo tanto, aumentando el acoplamiento? ¿Cuáles son las compensaciones en tiempo/costo/mantenimiento por ser 100% DRY para un método simple como GetTotal()? ¿Violar DRY cuando tiene sentido en realidad disminuye la complejidad y el costo general de mantener su base de código?

Lamento haber respondido con tantas preguntas pero espero que ahora pueda ver los matices y las complejidades de la pregunta que hizo. ;)

Answer 2

También se podría observar que el no uso de modelos de vista sería una violación del principio de responsabilidad única: su entidad no debería estar contaminada con problemas de UI.

También creo que el valor real de los modelos de vista no se manifiesta necesariamente en la versión 1.0 de su aplicación. Te agradecerás a ti mismo cuando trabajes en la versión 2.0 cuando vuelvas a pensar por completo cómo funciona tu back-end, pero no tienes que llevar esos cambios a la capa de visualización.