Jaki jest najlepszy sposób na zbudowanie modelu widoku?

Question

Używam asp.net mvc ze strukturą encji i zaczynam uczyć się DDD. Pracuję nad projektem, który zawiera ankiety. Oto mój model domeny:

public class Survey 
{ 
    public int? SurveyID { get; set; } 
    public string Name { get; set; } 
    public decimal MinAcceptanceScore { get; set; } 
    public int UserFailsCount { get; set; } 

    public IEnumerable<SurveyQuestion> Questions { get; set; } 
    public IEnumerable<Prize> Prizes { get; set; } 
    public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
} 

muszę różne części badań dla różnych widoków, więc stworzyliśmy różne ViewModels:

public class ShortSurveyViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public int UserFailsCount { get; set; } 
     public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
    } 

    public class ShortSurveyWithPrizesViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public int UserFailsCount { get; set; } 
     public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
     public IEnumerable<Prize> Prizes { get; set; } 
    } 

    public class SurveyEditViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public decimal MinAcceptanceScore { get; set; } 
     public int UserFailsCount { get; set; } 

     public IEnumerable<SurveyQuestion> Questions { get; set; } 
     public IEnumerable<Prize> Prizes { get; set; } 
    } 

Jaki byłby najlepszy sposób na budowanie mojego architekturę, jeśli chcę mój repozytorium ankiet w celu uzyskania informacji potrzebnych do modelu podglądu aproperty?

Różne solusions które widzę:

1. Repository może powrócić IQueryable do SurveyService i serwisu może powrócić widoku modelu appropriete, ale waham się, że robi to w porządku, ponieważ myślę, zobacz modele powinny być tworzone w interfejsie , a nie warstwa Service.

2. Utwórz trzy odpowiednie klasy w mojej warstwie domeny. Ale teraz domena będzie zależna od reprezentacji i przy każdym nowym widoku powinna zostać utworzona nowa klasa domeny.

3. Pobierz pełny obiekt domeny i odwzoruj tylko właściwości potrzebne dla określonego widoku. To nie jest dobre, ponieważ na moim przykładzie pytania były potrzebne tylko w jednej reprezentacji i może to być duża kolekcja.

Answer 1

Domain Driven Design:

• Trzeba repozytorium powracającego łączną root - w przypadku Survey i wszystkie relacje, które nie mogą istnieć bez rodzica Survey
• To repozytorium będzie ładować zawsze cały Survey klasę iw zależności od Twoje wymagania to tylko niektóre relacje (naprawdę dogmatyczny DDD zawsze ładowałby cały agregat, ale to nie jest dobre podejście do bezpaństwowej sieci).
• Twoja warstwa aplikacji (kontroler) zapyta repozytorium o numer Survey oraz wybrane relacje i wypełni modele widoku.

Cebula architektura:

• Będziesz tworzyć jakieś repozytorium narażając IQueryable<Survey> - co gorsza będzie używany rodzajowe repozytorium z interfejsu CRUD
• Będziesz tworzyć jakąś służbę wzywającą repozytorium oraz budowania LINQ-podmioty rzutowanie na swoje DTO i zwracanie ich do warstwy aplikacji (kontrolera)
• Co teraz? Możesz użyć tych DTOs bezpośrednio lub użyć innego zestawu obiektów wykorzystywanych jako Pana zdaniem niektórych modelach z UI podobne atrybuty itd. Istnieje oczywiście coś nie tak ...

Prosta architektura:

• Będziesz zastosowanie wstrzykuje IDbSet<Survey> bezpośrednio w kontrolerze jako repozytorium
• zrobisz LINQ-podmioty bezpośrednio projekcje w kontrolerze do wypełnienia zobacz modele

Ther e nie jest najlepszym sposobem. Zawsze chodzi o twój cel i twoje oczekiwania. W przypadku małych aplikacji można żyć z prostą architekturą bez żadnego problemu.

Projektowanie oparte na domenach jest bardziej złożone. Główną koncepcją DDD są encje domeny, obiekty wartości i ich skład. Domena enkapsuluje dane i logikę wykonywaną na tych danych. DDD nie działa z częściowymi danymi lub DTO - kiedy twoje domeny nie mają żadnej logiki, robisz to źle (nazywa się to anemicznym modelem). Usługa w DDD nie jest mediatorem między warstwą aplikacji a repozytorium. Służy do obsługi logiki biznesowej, która nie jest powiązana z jednostką jednej domeny (dlatego nie może być enkapsulowana w jednostce domeny). Repozytorium to kod infrastruktury niezbędny do zmaterializowania agregatów z pamięci masowej i utrzymywania ich w pamięci masowej. Logika aplikacji (kontroler) może wchodzić w interakcje z domenami, usługami i kodem infrastruktury.

Nie lubię architektury cebuli.

Answer 2

Biorąc pod uwagę fakt, że głównym problemem jest ilość danych pobierane z modelu danych w porównaniu z ilością danych, niezbędnych z punktu widzenia modelu, powiedziałbym odpowiednie podejście dla Ciebie byłoby zbudować widoków w baza danych i ich odpowiednie modele danych.

Dzięki temu można przycinać ilość danych pobranych z bazy danych podczas jednej podróży.

Chociaż modele danych prawie naśladują modele widoków, to nie stanowi to problemu, służą one dwóm różnym celom. Model widoku jest dla Widoku do wiązania - Model danych wie, jak pobierać i zapisywać dane. Zbudowanie tych widoków pozwoliłoby uzyskać optymalne dane - a mimo to umieścić niestandardową logikę zapisu w tych samych modelach, aby można je było zapisywać w razie potrzeby - w związku z tym powstaje potrzeba przenoszenia danych z jednego modelu danych do następnego.