Tengo las siguientes capas en mi solución:
- App.Domain
- App.Service
- App.Core (tal vez llame a este App.DataLayer)
- App.Web
El patrón de diseño del software no es mi pregunta, tengo el siguiente modelo en Domain
public class Foo {
public int Id {get;set;}
public int Name {get;set;}
public int Value {get;set;}
}
Quiero usar este modelo en la vista (por ejemplo, página de inicio) Y quiero usar Id, Name & Value
, así que si quiero crear ViewModel, agregaré lo siguiente:
public class FooViewModel {
public int Id {get;set;}
public int Name {get;set;}
public int Value {get;set;}
}
Entonces, ¿es buena idea? o simplemente usar en Foo
lugar de FooViewModel
?
asp.net-mvc
model
Mehdi Dehghani
fuente
fuente
Model
se pasa generalmente a laView
? ¿Por qué exactamente necesita recrear los campos deModel
en elView
? Si el objetivo es la separación de las preocupacionesMVC
, ¿en qué circunstancias querría hacer lo mismo conModel
yView
? SiViewModel
es ambos, ¿por qué no extendiendo / componiendo ambosModel
yView
?Respuestas:
Esto puede parecer una violación de la regla DRY inicialmente, pero diría que un código "similar e incluso idéntico" no es necesariamente una "repetición" si hace algo diferente o puede cambiar de forma independiente. Y en el caso de los modelos de vista, el código define lo que ve el "cliente", no necesariamente las entidades y operaciones de las que habla el negocio. Por lo tanto, a menudo revela modelos al cliente o interfaz que son "incidentalmente idénticos". Puede cambiar las reglas y términos comerciales o la terminología del usuario final independientemente uno del otro.
Entonces, volvería a hacerte la pregunta. Si el dominio cambia, ¿es aceptable que los clientes de la "versión 1" sigan usando las interfaces antiguas? ¿Revelarás alguna vez términos u operaciones en la interfaz que no formen parte de las "reglas comerciales básicas"? ¿Y viceversa?
Ese tipo de preguntas en mente, si la "función" de su vista es revelar estrictamente el modelo de dominio subyacente, sí, parece que viola la regla DRY.
También tenga en cuenta que exponer una visión que cambia más naturalmente con los cambios del modelo también se puede lograr en algunos idiomas con atributos y reflexión de miembros. (O con menos repetición a través de otras hazañas de inteligencia ... Pero, la "inteligencia" a menudo no puede justificar la repetición que te ahorra).
fuente
Foo
, así que si lo usabaFoo
como ViewModel también, el cliente obtendrá nuevas propiedades también, entonces, ¿qué pasa si este nuevo fuera un campo de seguridad (tal vez verdadero / falso para obtener permiso, o algo así), ¿qué debo hacer?User edit form
, no necesitamos pasar elIsAdmin
campo al cliente, para mantener este campo seguro, así que esto es lo que me preocupa. Perdón por mi mal ingles.Tendría un modelo de vista que contiene solo una propiedad, una instancia de Foo. De esa manera, no está violando DRY de acuerdo con ninguna definición de este, si Foo cambia, su modelo de vista ve automáticamente el cambio y se libera de un vínculo directo del modelo de vista con el modelo.
Si mañana es necesario que la vista muestre algo más, así como el Foo, puede agregar una nueva propiedad, y la intención de su modelo de vista seguirá siendo clara, contiene un Foo y algo más, no tendrá Una mezcla de propiedades de Foo con otras propiedades no relacionadas.
No pensaría en su modelo de vista como un FooViewModel, lo pensaría en términos de lo que se supone que debe mostrar la vista. Si solo muestra un Foo, el modelo de vista contiene una propiedad, un Foo.
No estoy seguro si lo expliqué claramente. Si no es así, ¡hágamelo saber y trataré de reformularlo cuando esté despierto!
fuente
Yo diría que usar
FooViewModel
de esta manera viola el director DRY. Cuando necesite hacer un cambioFoo
, también debe hacerloFooViewModel
. Creo que sería mejor servirlo simplementeFoo
como modelo para su vista. Consideraría un modelo de vista si necesita mostrar cosas de Foo y algo más. Por ejemplo, supongamos que necesita representar cierta información desdeFoo
y también desdeBar
.fuente
Foo
, así que debido a que también utilicéFoo
como ViewModel, así que también tengo que pasar este nuevo campo a la vista, creo que este no es un buen negocio, ¿qué cree? ?Foo
yFooViewModel
. En general, no es una buena idea tener que modificar varios archivos para un solo cambio lógico.true/false
valor para el permiso o algo así?