Czyli sugerujesz, że najpierw powinienem sobie w serwisie zweryfikować poprawność danych w DTO i w razie błędu zwrócić komunikat o błędzie.
Tak, tylko nie bezpośrednio w serwisie lecz w jakimś wydzielonym walidatorze. No i też, żeby nie wynajdować koła na nowo lepiej użyć sprawdzonej biblioteki.
Następnie na jego [DTO] podstawie tworzyć sobie obiekt Category
, który potem sobie np. zapiszę do bazy danych? Czyli w klasie Category
i tak powinienem powtórzyć sprawdzanie poprawność danych, z tymże rzucając wyjątki w razie nieprawidłowości (bo jakimś cudem wartość będzie niepoprawna)?
Dla bezpieczeństwa rzucałbym wyjątek, bo nigdy nie powinno się dać utworzyć zepsutego obiektu. A to może nastąpić, np.:
- walidacja się zepsuje, a nie jest dostatecznie pokryta testami;
- pojawi się nowy flow, w którym obiekt domenowy będzie tworzony nie z DTO, więc nie będzie uprzedniej walidacji.
Ogólnie, walidacja służy do tego, aby powiedzieć użytkownikowi, co zrobił źle, a niezależnie od niej, to obiekt powinien być sam w sobie zabezpieczony przed utworzeniem go w sposób, w którym nie będzie działał poprawnie.
PS. No i nie zapisywałbym obiektów domenowych do bazy danych. Chyba, że to jakiś anemiczny crud, a domena to tak naprawdę DTO. Ale to chyba nie ten przypadek, skoro masz konstruktory i nie masz setterów.