MVC Repository - Modelo de dominio vs Entity Model

Question

He creado un repositorio que devuelve datos de mi base de datos utilizando Entity Framework y necesito proporcionar estos datos a mi vista, pero antes de hacerlo necesito convertir esos objetos en mi modelo de dominio.

Mi esquema es el siguiente:

TABLE Project 
    Id INT PRIMARY KEY 
    Name NVARCHAR(100) 

TABLE Resource 
    Id INT PRIMARY KEY 
    FirstName NVARCHAR(100) 
    LastName NVARCHAR(100) 

TABLE ProjectResources 
    Project_Id INT PRIMARY KEY -- links to the Project table 
    Resource_Id INT PRIMARY KEY -- links to the Resource table 

me genera un modelo de entidad que terminó con este aspecto:

Project 
| 
---->ProjectResources 
    | 
    ---->Resource 

Tengo un repositorio que devuelve un Proyecto:

public interface IProjectRepository 
{ 
    Project GetProject(int id); 
} 

Y una acción de controlador:

public ActionResult Edit(int id) 
{ 
    Project project = projectRepository.GetProject(id); 

    return View(project); 
} 

Esto no parece funcionar muy bien cuando intento y PUBLICAR esta información. Obtenía un error EntityCollection ya inicializado cuando intentaba reconstruir la colección ProjectResources.

creo que es más inteligente para crear un modelo de dominio que es un poco más simple:

public class ProjectEdit 
{ 
    public string ProjectName { get; set; } 
    public List<ProjectResource> Resources { get; set; } 
} 

public class ProjectResource 
{ 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
} 

Esto parece ser un poco más agradable ya que también no tengo los intermedios ProjectResources -> salto de recursos. ProjectResource tendría los campos que necesito. En vez de hacer algo como:

@foreach(var resource in Model.ProjectResources) { 
    @Html.DisplayFor(m => m.Resource.FirstName) 
} 

que puedo hacer:

@foreach(var resoure in Model.Resources) { 
    @Html.DisplayFor(m => resource.FirstName); 
} 

Mi pregunta es la siguiente ¿Debo estar regresando a mi modelo de dominio de mi repositorio o debería que ser manejado por el controlador o alguna otra clase en el medio? Si se maneja en el controlador por algo que mapea mi proyecto a un ProjectEdit, ¿qué aspecto tendría?

Answer 1

Mi propia opinión es que no debe devolver nada a su controlador o una vista que depende de la implementación de su repositorio.

Si usa EF con el generador de POCO, es razonable usar esas clases para su modelo de dominio porque son independientes de la implementación de EF (podría reemplazar EF y retener los POCO).

Pero si utiliza EF con sus EntityObjects, creo que debe convertir a su modelo de dominio. Si su acceso a datos estaba encapsulado en un servicio WCF que utilizaba un patrón de repositorio internamente, no me preocuparía mucho devolver EntityObjects desde el repositorio. Pero si está utilizando un Repositorio directamente desde MVC, use el Modelo de Dominio como interfaz para el Repositorio.

Answer 2

Lo que describes es exactamente lo que he estado haciendo durante años, tratando de seguir el diseño de aplicaciones de n niveles.

Porque sus datos no siempre se organizarán de la misma manera que su dominio. Lo que hace que en SQL no siempre sea el mismo en su dominio, como lo ha visto aquí.

Normalmente, mi dominio sabe cómo se ve el repositorio y tiene métodos para convertir desde y hacia.Mi UI/views sabe cómo es el dominio y tiene métodos para recuperar esos datos (eso va en el controlador).

Así que respuesta corta, diría, algo en el medio (su capa de negocios) y que expone los métodos utilizables por sus controladores para recibir esos datos.

Answer 3

Tenemos la tendencia a usar siempre un modelo de vista como "la clase en el medio" y el mapa hacia y desde el modelo real utilizando ...

Automapper

... o ...

ValueInjecter

Su ViewModel puede ser bastante independiente de su modelo en términos de estructura, si así lo desea.