Walidacja po stronie klienta (walidacja w warstwach prezentacji)

Wskazówka

Ta treść jest fragmentem eBooka "Architektura mikrousług .NET dla konteneryzowanych aplikacji .NET", dostępnego na .NET Docs lub jako bezpłatny plik PDF do pobrania i czytania w trybie offline.

Pobierz plik PDF

Nawet jeśli źródłem prawdy jest model domeny i ostatecznie musisz mieć walidację na poziomie modelu domeny, walidacja nadal może być obsługiwana zarówno na poziomie modelu domeny (po stronie serwera), jak i interfejsie użytkownika (po stronie klienta).

Walidacja po stronie klienta jest doskonałym rozwiązaniem dla użytkowników. Oszczędza to czas, jaki w przeciwnym razie spędziliby na oczekiwaniu na komunikację z serwerem, który może zwrócić błędy walidacji. Z biznesowego punktu widzenia, nawet kilka ułamków sekund mnożone setki razy każdego dnia składa się na dużo czasu, wydatków i frustracji. Prosta i natychmiastowa walidacja umożliwia użytkownikom wydajniejszą pracę i uzyskanie lepszej jakości danych wejściowych i wyjściowych.

Podobnie jak model widoku i model domeny są różne, walidacja modelu widoku i walidacja modelu domeny mogą być podobne, ale służą innemu celowi. Jeśli martwisz się o zasadę DRY (Nie powtarzaj siebie), warto wziąć pod uwagę, że w tym przypadku ponowne użycie kodu może również oznaczać sprzężenie, a w aplikacjach korporacyjnych ważniejsze jest, aby nie łączyć strony serwera ze stroną klienta niż przestrzegać zasady DRY.

Nawet w przypadku korzystania z weryfikacji po stronie klienta zawsze należy zweryfikować polecenia lub wejściowe obiekty DTO w kodzie serwera, ponieważ interfejsy API serwera są możliwym wektorem ataku. Zazwyczaj najlepszym rozwiązaniem jest robienie obu rzeczy, ponieważ, jeśli masz aplikację kliencką, z punktu widzenia UX najlepiej jest działać proaktywnie i nie pozwalać użytkownikowi na wprowadzanie nieprawidłowych informacji.

W związku z tym w kodzie po stronie klienta zwykle sprawdzasz poprawność modelu ViewModels. Przed wysłaniem ich do usług można również zweryfikować wyjściowe obiekty DTO lub polecenia klienta.

Implementacja weryfikacji po stronie klienta zależy od rodzaju tworzonej aplikacji klienckiej. Będzie to wyglądało inaczej, gdy sprawdzasz dane w aplikacji internetowej MVC z większością kodu na platformie .NET, w przeciwieństwie do aplikacji internetowej SPA z kodem walidacyjnym w języku JavaScript lub TypeScript.

Dodatkowe zasoby

Walidacja w aplikacjach ASP.NET Core

• Dodawanie walidacji
  https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation

Walidacja w aplikacjach internetowych SPA (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)

• Walidacja formularza
  https://angular.io/guide/form-validation

• Walidacja. Dokumentacja Breeze.
  https://breeze.github.io/doc-js/validation.html

• Formularze i składniki wejściowe ASP.NET Core Blazor \ </aspnet/core/blazor/forms-and-input-components>

Podsumowując, są to najważniejsze pojęcia dotyczące walidacji:

• Jednostki i agregacje powinny wymuszać własną spójność i być "zawsze prawidłowe". Zagregowane korzenie są odpowiedzialne za spójność wielu jednostek w ramach tej samej agregacji.

• Jeśli uważasz, że jednostka musi wprowadzić nieprawidłowy stan, rozważ użycie innego modelu obiektów — na przykład przy użyciu tymczasowego obiektu DTO do momentu utworzenia jednostki domeny końcowej.

• Jeśli musisz utworzyć kilka powiązanych obiektów, takich jak agregat, i będą one prawidłowe dopiero po utworzeniu wszystkich, rozważ użycie wzorca fabryki.

• W większości przypadków nadmiarowa walidacja po stronie użytkownika jest dobra, ponieważ aplikacja może być proaktywna.

PoprzedniNastępny