Violencia del patrón de Model-View-ViewModel de DRY?

Question

He leído este artículo hoy http://dotnetslackers.com/articles/silverlight/Silverlight-3-and-the-Data-Form-Control-part-I.aspx sobre el uso del patrón MVVM dentro de una aplicación de Silverlight donde tienes tus entidades de dominio y ves entidades específicas que básicamente son un subconjunto de los objetos de la entidad real. ¿No es esto una clara violación del principio DRY? y si es así, ¿cómo puedes manejarlo de una manera agradable?

Answer 1

Personalmente, no me gusta lo que Dino está haciendo allí y no abordaría el problema de la misma manera. Normalmente pienso en una VM como una colección filtrada, agrupada y ordenada de clases de modelos. Una máquina virtual para mí es una asignación directa a la vista, por lo que podría crear una clase NewOrderViewModel que tenga múltiples vistas de colección utilizadas por la vista (tal vez un CV para clientes y otro CV para productos, probablemente ambos filtrados). Crear una clase de VM completamente nueva para cada clase en el Modelo viola DRY en mi opinión. Preferiría usar derivación o clases parciales para aumentar el Modelo donde sea necesario, agregando propiedades de Vista específica (a menudo calculadas). IMO .NET RIA Services es una excelente implementación de la combinación de datos M y VM con la ventaja añadida de que se puede usar tanto en el cliente como en el servidor. Dino es un tipo brillante, pero es una forma de llamarlo en este caso.

Answer 2

DRY es un principio, no es una regla difícil. Eres un humano y puedes diferenciar. P. ej. Si DRY realmente era una regla difícil, nunca asignarías el mismo valor a dos variables diferentes. Supongo que en cualquier programa no trivial tendría más de una variable que contiene el valor 0.

Hablando en general: DRY no suele aplicarse a los datos. Aquellos que ven entidades específicas probablemente solo sean objetos de transferencia de datos sin ninguna lógica notable. Los datos pueden duplicarse por todo tipo de razones.

Answer 3

Creo que la respuesta realmente depende de lo que sientas que debería ser en ViewModel. Para mí, ViewModel representa el modelo de la pantalla que se muestra actualmente.

Por lo tanto, para algo así como ViewCategoryViewModel, no tengo una duplicación de los campos en Categoría. Expongo un objeto Category como una propiedad en el ViewModel (debajo de decir "SelectedCategory"), cualquier otro dato que la vista necesite mostrar y los comandos que esa pantalla puede tomar.

Siempre habrá alguna similitud entre el modelo de dominio y el modelo de vista, pero todo se reduce a la forma en que elija crear ViewModel.

Answer 4

Es lo mismo que con Objetos de transferencia de datos (DTO).

El dominio para esos dos tipos de objetos es diferente, por lo que no es una violación de DRY.

Consideremos el siguiente ejemplo:

class Customer 
{ 
    public int Age 
} 

Y una vista de modelo corsponding:

class CustomerViewModel 
{ 
    public string Age; 

    // WPF validation code is going to be a bit more complicated: 
    public bool IsValid() 
    { 
     return string.IsNullOrEmpty(Age) == false; 
    } 
} 

dominios Differnt - tipos de propiedad differnet - diferentes objetos.