Repozytorium MVC - Model domeny a model podmiotu

Question

Utworzyłem repozytorium, które zwraca dane z mojej bazy danych za pomocą Entity Framework i muszę dostarczyć te dane do mojego widoku, ale zanim to zrobię, muszę przekonwertować te obiekty na moje model domeny.

Mój schemat wygląda tak:

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 

I generowane modelu podmiotu, który zakończył się wyglądać jak ten:

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

Mam repozytorium, które zwraca Projekt:

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

A działanie kontrolera:

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

    return View(project); 
} 

Nie wydaje się to działać bardzo dobrze, gdy próbuję i POST tych danych. Otrzymałem już zainicjowany błąd EntityCollection podczas próby odtworzenia kolekcji ProjectResources.

myślę, że jest mądrzejszy, aby utworzyć model domeny, która jest trochę prostsza:

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; } 
} 

To wydaje się być trochę ładniejszy od ja też nie mają pośrednie ProjectResources -> skok zasobów. ProjectResource miałby pola, których potrzebuję. Zamiast robić coś takiego:

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

mogę zrobić:

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

Moje pytanie brzmi następująco powinienem wracać mojego modelu domeny z mojego repozytorium czy powinno być obsługiwane przez kontroler lub jakiejś innej klasy w środku? Jeśli jest on obsługiwany w kontrolerze przez coś, co odwzorowuje mój projekt na ProjectEdit, jak by to wyglądało?

Answer 1

Mój własny widok polega na tym, że nie należy zwracać niczego do kontrolera lub widoku zależnego od implementacji repozytorium.

Jeśli używasz EF z Generatorem POCO, rozsądne jest używanie tych klas dla twojego modelu domeny, ponieważ są one niezależne od implementacji EF (można zastąpić EF i zachować POCO).

Ale jeśli używasz EF z EntityObjects, uważam, że powinieneś przekonwertować na swój model domeny. Jeśli twój dostęp do danych został hermetyzowany w usłudze WCF, która wewnętrznie używała wzorca repozytorium, nie martwiłbym się zbytnio powracaniem EntityObjects z repozytorium. Ale jeśli używasz repozytorium bezpośrednio z MVC, użyj Modelu Domeny jako interfejsu do repozytorium.

Answer 2

To, co opisujesz, jest dokładnie tym, co robiłem od lat, wiążąc się z n-warstwowym projektowaniem aplikacji.

Ponieważ dane nie będą zawsze uporządkowane w taki sam sposób jak domeny. To, co sprawia, że ​​w SQL nie zawsze jest taka sama w Twojej domenie, jak tutaj.

Zazwyczaj moja domena wie, jak wygląda repozytorium i ma metody konwersji do i od.Moje UI/widoki wiedzą, jak wygląda domena i mają metody pobierania tych danych (które znajdują się w kontrolerze).

Tak krótka odpowiedź, powiedziałbym, coś pośrodku (twoja warstwa biznesowa) i ujawniam metody używane przez kontrolerów do otrzymywania tych danych.

Answer 3

Mamy tendencję, aby zawsze używać ViewModel jako „klasy w środku” i mapować do iz rzeczywisty model używając ...

Automapper

... albo ...

ValueInjecter

Twój ViewModel może być wtedy dość niezależny od modelu pod względem struktury, jeśli chcesz.