• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Spring - najlepsza metoda sprawdzania poprawności parametrów obiektów domenowych

VPS Starter Arubacloud
0 głosów
145 wizyt
pytanie zadane 14 czerwca 2019 w Java przez niezalogowany
Hej!

W swoich prostych projektach naprzemiennie stosuję dwa podejścia:
- walidacja poprzez adnotacje

- walidacja poprzez metody

Przykład: mam kontroler restowy, który jest zmapowany na ścieżkę "/register" i służy do przyjęcia jsona, jako parametr ma wpisane: (@RequestBody UserDto userDto)

I teraz mogę albo w tym kontrolerze odwołać się do metody, którą stworzę i metoda ta będzie sprawdzała poprawność parametrów obiektu userDto lub mogę dodać odpowiednie adnotacje w klasie UserDto.

Które podejście jest lepsze i dlaczego?
A może taka walidacja powinna odbywać się po stronie frontu?

https://twitter.com/odrotbohm/status/1055015506326052865

1 odpowiedź

0 głosów
odpowiedź 14 czerwca 2019 przez Aisekai Nałogowiec (42,190 p.)
wybrane 15 czerwca 2019
 
Najlepsza

To zależy. Osobiście nie korzystam z walidowania przez adnotacje, bo wprowadza to samowalidujące się obiekty (a to utrudnia potem możliwość ponownego ich użycia w innym projekcie). 

https://softwareengineering.stackexchange.com/questions/119778/where-we-should-put-validation-for-domain-model

Teraz czy walidować przez metody (obiektów wyspecjalizowanych), czy po stronie frontendu? To zależy. Walidowanie, czy np użytkownik o podanym adresie email istnieje powinno być po stronie backendu. Czy nazwa użytkownika ma określoną długość - to już zależy według mnie od założeń, ale zastanowiłbym się czy nie zostawić tego po stronie frontendu, 

https://www.quora.com/Should-I-do-input-validation-on-the-front-end-or-back-end

 

komentarz 14 czerwca 2019 przez mbabane Szeryf (79,280 p.)

to już zależy według mnie od założeń, ale zastanowiłbym się czy nie zostawić tego po stronie frontendu,

Pamiętaj, że w niektórych przypadkach JavaScript'y można wyłączyć, bądź wyedytować HTML'a i  zmienić np. type=email na type=text.

Walidacja po stronie backendu jest najpewniejsza i konieczna jeśli udostępniamy API gdzie każdy może dopisać sobie "front-end".

komentarz 14 czerwca 2019 przez Aisekai Nałogowiec (42,190 p.)
Tak jak mówię, według mnie wszystko zależy od założeń. Zdaję sobie sprawę że JS można wyłączyć czy zmodyfikować HTML ręcznie, tylko jedno pytanie. Po co? Jeżeli jakiś użytkownik poda email niezgodny z formatem, to nie odbierze wiadomości..Jeżeli użytkownik stworzy zbyt krótkie hasło i zbyt krótki login to sam siebie naraża. Jeżeli system nie ma narzuconych jakichś wymogów, albo z jakiejś innej przyczyny nie wymaga tego żeby dane miały odpowiedni format to według mnie nie ma sensu obciążać serwera.

Przy założeniu, że nie chcemy np przechowywać loginów w systemie w którym znajdują się jakieś niecenzuralne słowa - to jak najbardziej, tutaj walidacja musi być po stronie systemu.
1
komentarz 14 czerwca 2019 przez mbabane Szeryf (79,280 p.)

Jeżeli jakiś użytkownik poda email niezgodny z formatem, to nie odbierze wiadomości..J

Możesz się przez to narazić na jakiś nieprzewidziany błąd w bibliotece do wysyłania maili i będzie trzeba robić jakieś druty lub specjalną obsługę błędów co defacto jest w pewnym stopniu walidacją. Długości pól też są ważne żeby np. ktoś nie robił requestów z 50000 znaków w polu - a zrzekając się tego na samą bazę danych jeszcze bardziej obciąża to system bo request przechodzi przez wszystkie moduły, front, back, baza (w najprostszym przypadku). Mając standardową walidację zatrzyma się co najmniej na backendzie.

komentarz 14 czerwca 2019 przez Aisekai Nałogowiec (42,190 p.)
edycja 14 czerwca 2019 przez Aisekai
No okej, masz w sumie rację.

Edit: nie pomyślałem o tym, w ten sposób.
komentarz 15 czerwca 2019 przez niezalogowany
Dzięki, panowie!
komentarz 15 czerwca 2019 przez Aisekai Nałogowiec (42,190 p.)
@mbabane a co sądzisz, żeby serwer walidował nie pod względem jakości (tak jak mówiłem, dowolna nazwa użytkownika, nawet jednoznakowa) natomiast, z ograniczeniem co do wydajności/zajętości pamięci dla jednego użytkownika (np walidowanie tylko długości nazwy użytkownika - max 10 znaków). Według mnie, jest to kompromis który gwarantuje odciążenie serwera.
komentarz 15 czerwca 2019 przez mbabane Szeryf (79,280 p.)

Rozumiem, że pod hasłem jakość chodzi Ci o to że np. w pole imię można wstawić lub nie znak nawiasu, średnika itp. 

Pewnie to zależy od domeny. Jeśli będzie to np. forum internetowe jak to, to podanie imienia w formularzu jako np.

K@©p3®

raczej nie będzie wielkim zgrzytem. Ale np. jeśli będzie to aplikacja banku/sklepu może być z tym problem np. przy wystawieniu faktury.

Długości pól według mnie trzeba sprawdzać bez względu na domenę.

Jeden rodzaj wprowadzanych danych wymaga silnej walidacji. Są to daty. Do operacji na datach stosuje się dedykowane klasy (w przypadku Javy LocalDate; bazy danych też mają analogiczne) więc one muszą być sprawdzane dość dokładnie (zresztą wspomniany LocalDate to robi). No i dochodzą jeszcze tzw. patterny. Jedni będą używać myślników jako separator, jedni kropki. Kolejność może mieć także znaczenie np. MM-DD-YYYY czy YYYY.MM.DD.

Podobne pytania

0 głosów
1 odpowiedź 381 wizyt
pytanie zadane 15 lutego 2019 w Java przez niezalogowany
0 głosów
0 odpowiedzi 657 wizyt
pytanie zadane 15 marca 2017 w Java przez Swierzak Użytkownik (690 p.)
0 głosów
1 odpowiedź 424 wizyt
pytanie zadane 26 marca 2018 w Java przez LockeLamora Użytkownik (740 p.)

92,454 zapytań

141,263 odpowiedzi

319,099 komentarzy

61,854 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...