2013-07-18 12 views
19

Jeśli zostanie wykonana client validation, gdy konieczne będzie wykonanie domain level validation?Wyświetl weryfikację modelu i sprawdzanie poprawności modelu domeny

Używam ASP.NET MVC dla moich aplikacji internetowych. Lubię rozróżniać moje domain models i . Moje modele domen zawierają dane pochodzące z mojej bazy danych, a modele widoków zawierają dane dotyczące moich widoków/stron.

Powiedzmy, że pracuję z danymi klientów.

Będę miał tabelę w mojej bazie danych o nazwie Customers.

będę mieć klasę klienta, który mógłby wyglądać następująco:

public class Customer 
{ 
    public int Id { get; set; } 

    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

I będę CREATE VIEW klient modelu reprezentować tylko tych danych, które mam na moim zdaniem:

[Validator(typeof(CustomerCreateViewModelValidator))] 
public class CustomerCreateViewModel 
{ 
    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

Będę miał widok utworzenia, który akceptuje mój CustomerCreateViewModel i wiąże moje pola wejściowe z moim modelem widoku:

@model MyProject.ViewModels.Customers.CustomerCreateViewModel 

@using (Html.BeginForm()) 
{ 
    <table> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.FirstName) 
        @Html.ValidationMessageFor(x => x.FirstName) 
       </td> 
      </tr> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.LastName) 
        @Html.ValidationMessageFor(x => x.LastName) 
       </td> 
      </tr> 
    </table> 

    <button id="SaveButton" type="submit">Save</button> 
} 

Jak widać, mam CustomerCreateViewModelValidator, który zawiera moje zasady sprawdzania poprawności. Po wprowadzeniu pewnych danych do pól tekstowych użytkownik kliknie przycisk przesyłania. Jeśli niektóre pola są puste, sprawdzanie poprawności nie powiedzie się. Jeśli wszystkie wymagane pola zostaną wprowadzone, sprawdzanie poprawności powiedzie się. Będę wtedy mapowania danych z mojego widoku modelu do mojego modelu domeny tak: model domeny

Customer customer = Mapper.Map<Customer>(viewModel); 

Ten klient mi zdać go na moim warstwy repozytorium i dodaje dane do mojego stolika.

Kiedy należy wykonać sprawdzanie poprawności w modelu domeny? Wszystkie moje walidacje sprawdzam na moim modelu widoku. Czy mogę zweryfikować swoje dane w moim modelu domeny tuż przed dodaniem go do bazy danych, ale widząc, że został on sprawdzony w modelu widoku, czy nie byłoby to po prostu replikowanie tego samego sprawdzania poprawności po stronie klienta?

Czy ktoś mógłby podzielić się niektórymi informacjami na temat tej procedury sprawdzania oryginalności?

+0

Czy masz oddzielne reguły sprawdzania poprawności między warstwami? Mam na myśli to, czy jest możliwe, aby coś ważnego w UI nie było uważane za ważne w domenie? –

+0

W tej chwili oba powinny być takie same. Generalizuję weryfikacje, nie tylko specyficzne dla moich projektów. –

+1

Byłbym jednak przekonany, że DDD skłania się do metody instancji 'Validate()' na każdym obiekcie domeny, który się sprawdza. Jestem jednak najdalej od eksperta od DDD. +1 za interesujące pytanie. –

Odpowiedz

9

Zawsze zatwierdzaj na obu poziomach.

Musisz zweryfikować modele widoku, ponieważ chcesz je przekazać użytkownikowi tak szybko i łatwo, jak to możliwe, jeśli zrobiły coś nie tak. Nie chcesz też zawracać sobie głowy resztą logiki domeny, jeśli model jest nieprawidłowy.

Należy jednak sprawdzić, czy wszystko jest szczęśliwe w domenie po sprawdzeniu poprawności modelu widoku. W przypadku prostych modeli te kontrole mogą być takie same i dlatego wyglądają jak logika powielania, jednak gdy tylko aplikacja się powiększy, więc możesz mieć wiele interfejsów użytkownika lub wiele różnych aplikacji używających tych samych modeli domen, staje się tak ważne, aby sprawdź w domenie.

Na przykład, jeśli aplikacja rośnie, dzięki czemu można uzyskać interfejs API do klientów, aby mógł bezpośrednio współpracować z aplikacją, konieczne staje się sprawdzenie modeli domen, ponieważ nie można zagwarantować, że używany interfejs użytkownika danych do standardu, którego potrzebujesz (lub nawet w ogóle go zwalidował). Istnieje argument mówiący, że dane odbierane przez interfejsy API powinny być sprawdzane w taki sam sposób, jak sprawdzane są modele widoku, co jest prawdopodobnie dobrym pomysłem, ponieważ osiąga ten sam cel, co weryfikacja modelu widoku. Ale niezależnie od trasy (z interfejsu użytkownika lub interfejsu API), zawsze będziesz chciał zagwarantować, że dane są poprawne, dlatego określenie w centralnym miejscu jest idealne.

Cele obu poziomów walidacji są różne. Oczekuję sprawdzenia poprawności modelu widoku, aby poinformować mnie o problemach (takich jak brakujące imię, nazwisko jest zbyt długie, DoB nie jest datą). Sądzę jednak, że logika domeny może zakończyć się niepowodzeniem przy pierwszym błędzie i po prostu zgłosić tę. Ponownie, w przypadku prostych modeli może być możliwe zebranie wszystkich błędów i zgłoszenie ich wszystkich z powrotem, jednak im bardziej złożona aplikacja otrzyma, tym trudniej będzie przewidzieć wszystkie błędy, zwłaszcza jeśli logika zmieni się w zależności od danych. Ale tak długo jak tylko dobre dane przeminą, to powinno być dobrze!

0

Wymagany jest weryfikator modelu w przypadku kilku klientów dla danego modelu. Na przykład, jeśli masz ASP.NET MVC wywołujący twój model i aplikację WPF, w tym przypadku logiczne jest sprawdzanie poprawności w modelu. Ale w twoim przypadku, gdy masz tylko jednego klienta, który byłby przesadny.

+0

Więc mówisz, że jeśli masz tylko jedną aplikację, która korzysta z bazy danych, wystarczy walidacja w modelu widoku? –

+1

Co im 'mówię, że jeśli korzystasz z repozytorium tylko od jednego klienta tak oczywiste, walidacja na ViewModel będzie wystarczająca, ponieważ nie będzie żadnych innych sposobów, aby dostać się do repozytorium, tylko przez kontrolery, które wywołują logikę walidacji –

+2

To prowadzi do anemicznego modelu domeny. Twój model domeny musi chronić niezmienniki. – JefClaes

2

Mam tendencję do myślenia o walidacji klienta jako bardziej oczyszczającej dane na poziomie interfejsu użytkownika. Innymi słowy, sprawdzenie, czy na przykład pole wejściowe, które jest liczbą, otrzymuje pewną liczbę od użytkownika. Lub czy długość wpisu tekstowego spełnia wymagania dotyczące minimalnej długości. Takie rzeczy.

Na poziomie domeny powinieneś sprawdzić reguły domeny biznesowej. Na przykład, jeśli użytkownik wprowadza dane o nowym produkcie, czy nazwa produktu już istnieje? A może sprawdzanie, czy użytkownik wybrał prawidłowy dział podczas konfigurowania nowego użytkownika na podstawie jego umiejętności? To tylko przykłady z powietrza, ale mam nadzieję, że dadzą pojęcie o tym, co mam na myśli.

6

Zasadniczo uważam model domeny za najważniejszy kod, a zatem zarządzanie jego świętym państwem.Z tego powodu nigdy nie zakładałbym, że model domeny jest w prawidłowym stanie, ponieważ był obsługiwany przez warstwę prezentacji, która ma wymuszać ważność. Oznaczałoby to, że twoja warstwa domeny jest ściśle powiązana z twoją warstwą prezentacji.

Najlepiej zacząć myśleć od modelu domeny na zewnątrz (onion architecture). Uzasadnieniem tego wszystkiego jest to, że model domeny jest najmniej prawdopodobny, aby z czasem zmienić się i działa jako rdzeń aplikacji, izolując warstwy od wad innych stron.

Rozpoczynając od modelu domeny, który wymusza własną ważność, pozostaje pytanie o powieleniu kodu walidacyjnego. Jest kilka sposobów na uniknięcie tego. Twój model widoku może na przykład spróbować utworzyć obiekt domeny i przetłumaczyć wszystkie wyjątki zgłoszone jako błędy sprawdzania poprawności. Walidatory można również wyodrębnić i ponownie użyć. W zależności od przypadków użycia musisz zobaczyć, co działa najlepiej. Tylko uważaj, aby to było proste. Być może, jeśli twoje przypadki użycia nie zostaną spełnione, możliwe, że po prostu potwierdzisz walidację. Pamiętaj, że deduplikacja zwiększa złożoność.

Widziałem podstawy kodu, w których tylko warstwa domeny obsługiwała sprawdzanie poprawności i bazy kodów, w których sprawdzano poprawność zarówno w warstwie domeny, jak i prezentacji. Preferuję po prostu powielanie logiki walidacji w tym momencie, ponieważ widziałem, jak trudno jest sensownie mapować błędy sprawdzania poprawności domen na kontekstowy interfejs użytkownika.

Powiązane problemy