Prácticas recomendadas del modelo de vista MVC de ASP.NET

Question

Mi sitio ASP.NET MVC se conecta a un servicio WCF para obtener datos. El servicio WCF devuelve un contrato de datos de esta manera:

[DataContract] 
public class Person 
{ 
    [DataMember] 
    public string First { get; set; } 

    [DataMember] 
    public string Last { get; set; } 
} 

el modelo de vista en mi proyecto MVC se ve así:

public class MyViewModel 
{ 
    public string SomeExtraField1 { get; set; } 
    public string SomeExtraField2 { get; set; } 
    public string SomeExtraField3 { get; set; } 

    public Person Person { set; set; } 
} 

En caso de que mi vista del modelo se hace referencia al contrato de datos "persona" que se devuelve del servicio de datos? ¿O debería crear una nueva clase "Persona" en mi proyecto MVC que refleje las propiedades en el contrato de datos "Persona"?

La llamada de servicio WCF está oculta detrás de una interfaz. Parece ser que tener la referencia de la interfaz del contrato de datos hace que mi interfaz sea una abstracción permeable. Sin embargo, tengo algunas personas que creen que la creación de una clase adicional de "Persona" en mi proyecto MVC que refleja el contrato de datos es un exceso de código.

¿Cuáles son las mejores prácticas que rodean este tipo de estratificación/desacoplamiento?

Answer 1

¿Debería mi modelo de vista hacer referencia al contrato de datos "Persona" que se devuelve desde el servicio de datos?

No, evite esto, le está dando a los desarrolladores la falsa impresión de que están usando modelos de vista. Con frecuencia veo código como este cuando hago revisiones de código:

public class MyViewModel 
{ 
    public SomeDomainModel1 Model1 { get; set; } 
    public SomeDomainModel2 Model2 { get; set; } 
    ... 
} 

y eso es simplemente incorrecto. Cuando los critico por no usar modelos de vista me muestran esto y me dicen: "Darin, mira, estoy usando modelos de vista", lamentablemente no es así como se supone que los modelos de vista funcionan. No son envoltorios de modelos de dominio.

¿O debería crear una nueva clase "Persona" en mi proyecto MVC que refleje las propiedades en el contrato de datos "Persona"?

Sí, podría crear un PersonViewModel e incluir solo las propiedades que su vista necesita, por supuesto.

O si la visión particular que está diseñando esta vista del modelo para las necesidades únicas de algunas propiedades que también podría hacer que se vea como esto:

public class MyViewModel 
{ 
    public string SomeExtraField1 { get; set; } 
    public string SomeExtraField2 { get; set; } 
    public string SomeExtraField3 { get; set; } 

    // this would be for example the concatenation of your domain model 
    // first name and last name as that's what this particular view needs to 
    // display 
    public string PersonFullName { set; set; } 
} 

En cuanto a la conversión entre los modelos de dominio y los modelos de vista está preocupado , AutoMapper es simplemente poner: excelente.

Answer 2

Yo diría crear una capa de Mapper que convierta entre la clase de persona WCF y la clase de persona "espejo". De esta forma, está vinculando su implementación de MVC con un POCO y no directamente con WCF. Esto agrega la capacidad de intercambiar WCF con otro servicio sin tocar MyViewModel en el futuro si es necesario (acoplamiento más flexible).