Jak radzić sobie z walidacją jednostki domeny przed jej utrwaleniem?

Question

Jednostka (powiedzmy UserEntity) ma sztywne reguły dotyczące jej właściwości i może istnieć w 2 stanach - trwała (co oznacza, że ​​ma wartość id) i jest już utrwalana (co oznacza, że ​​nie ma jeszcze modelu id).

Zgodnie z odpowiedzią na this question about how to handle required properties, "prawdziwa" UserEntity powinna być zawsze tworzona z przekazanym do konstruktora id.

Jednak gdy potrzebuję utworzyć new UserEntity z informacji wysłanych przez przeglądarkę, muszę mieć możliwość sprawdzenia poprawności informacji przed ich utrwaleniem w bazie danych.

W przeszłości po prostu tworzyłem pustą UserEntity (bez id), ustawiałem nowe właściwości i sprawdzałem je - ale w tym nowym, bezpieczniejszym sposobie myślenia o Jednostkach nigdy nie powinienem utwórz nową UserEntity bez jej id.

Nie chcę tworzyć DWÓCH miejsc, które znają metody sprawdzania poprawności właściwości UserEntity, ponieważ jeśli kiedykolwiek się zmienią (i będą), będzie to podwójny kod do aktualizacji i podwoi szanse na błędy.

Jak skutecznie scentralizować wiedzę o sprawdzaniu poprawności właściwości mojej jednostki?

Uwaga

Jeden pomysł miałem odbija in this question, w którym uważam przechowywania właściwości niepaństwowych, takich jak e-mail, hasło i nazwę w znormalizowanej wartości obiektu, który będzie wiedział o zasadach jego właściwości, mogą korzystać z różnych usług, takich jak kontroler, Validator i Repo lub Mapper.

Answer 1

po to są fabryki. do metody fabrycznej przekazujesz tylko te dane, które są wymagane do wymuszenia prawdziwych niezmienników UserEntity (trochę czasu, aby dowiedzieć się, jakie są twoje niezmienniki UserEntity i lepiej to zrobić ze swoimi ekspertami od domeny).

w metodzie fabrycznej utworzysz nowy Id i przekażesz go do konstruktora UserEntity.

Na tym etapie nie sądzę, że jest tak źle, aby odrzucić instancję, jeśli sprawdzanie poprawności wewnątrz konstruktora nie powiedzie się. w najgorszym przypadku - utraciłeś identyfikator ... nie jest to przypadek, który przypuszczalnie zdarza się dość często - przez większość czasu dane powinny być sprawdzane w kliencie.

Oczywiście inną opcją jest to, że w metodzie fabrycznej najpierw sprawdza się poprawność parametrów, a dopiero potem tworzy nowy identyfikator i przekazuje go do konstruktora UserEntity.

itzik saban

Answer 2

Moim zdaniem, należy zapisać() i load() metody należy robić zarówno sprawdzanie i ustawienie atrybutu ID. A tak przy okazji, jednostka bez Atrybutu tożsamości nie jest wcale bytem.

moim zdaniem atrybutem tożsamości powinny być zatwierdzone i zapewnił, kiedy jednostka jest w tranzycie np

ładowanie od db, ładuje z pliku lub (po) oszczędzania db tak że

jeśli ładowanie od db nie wyrzucić encja zapisująca do pliku db/file nie odrzuca obiektu.

Ponieważ sprawdzanie poprawności dziennika biznes/zachowanie itp i lepszy wzór, który będzie

Strategia Wzór (http://en.wikipedia.org/wiki/Strategy_pattern)

Answer 3

Chyba masz kilka opcji do rozważenia:

(1) Zastanów się pierwszy komentarz:

podmiotu (powiedzmy UserEntity) posiada sztywne zasady to properti es, i może istnieć w 2 stanach - trwa (co oznacza, że ​​ma ma identyfikator) i jest wstępnie utrwalany (co oznacza, że ​​nie ma jeszcze identyfikatora).

W tym miejscu już wspomniano, że walidacja w rzeczywistości zależy od tego, czy podmiot został utrzymany. Innymi słowy, jeśli podmiot nie został utrwalony, to musi on być ważny bez ID. Jeśli będziesz kontynuować tę specyfikację domeny, uważam, że walidacja powinna działać odpowiednio (np. Return isValid nawet bez identyfikatora, jeśli obiekt nie został utrwalony)

(2) Jeśli przyjmiesz "prawidłowe" oznacza, że ​​obiekt ma ID, musisz wygenerować identyfikator podczas tworzenia. W zależności od tego, w jaki sposób generowane są twoje identyfikatory, może to być trudne (np. Zapisać do bazy danych i zwrócić utworzony identyfikator lub wygenerować unikalne identyfikatory w jakiś sposób, lub ...)

Przy użyciu obu metod prawdopodobnie warto wdrożyć wspólną klasę podstawową.) dla Twojej jednostki (np. z identyfikatorem), aby zminimalizować duplikowanie walidacji w różnych stanach. Mamy nadzieję, że osłabi to również jednostki pochodne od wspólnej walidacji.

Answer 4

Tematem prawidłowego sprawdzania poprawności jest szara strefa.

Sprawdzanie poprawności jest zwykle rzutowane jako sprawdzanie niezmiennicze i kontekstowe. Weryfikacja niezmiennicza odnosi się do rzeczy, które zgodnie z twoją domeną problemową muszą być obecne, aby twój model działał prawidłowo w zamierzonej roli. Sprawdzanie kontekstualności dotyczy stanu, który jest ważny w danym kontekście użycia (np. Kontakt używany do wysyłania wiadomości e-mail wymaga adresu e-mail, ale nie potrzebuje numeru telefonu, kontakt używany do wysyłania korespondencji katalogowej wymaga adresu pocztowego, ale nie potrzebuje adresu e-mail itp.).

Jeśli chcesz być czysta architektonicznie, to technicznie kwestie dotyczące sprawdzania danych wejściowych (co twoi klienci wpisują w interfejs użytkownika) i stanu danego podmiotu to dwie różne sprawy. Idealnie byłoby, gdyby twoja domena nie miała wiedzy o konkretnym typie aplikacji, dla której został napisany i dlatego nie powinna być obciążona dostarczaniem komunikatów o błędach odpowiednich do użycia, bezpośrednio lub pośrednio, w wyświetlaniu komunikatów o błędach z powrotem do użytkownika. Stanowi to pewien problem, ponieważ może prowadzić do podwójnego lub potrójnego sprawdzania błędów (strona klienta, strona usługi, poziom domeny), więc wielu wybiera bardziej pragmatyczne podejście do radzenia sobie z większością walidacji zewnętrznej względem podmiotu (np. model wejściowy przed utworzeniem jednostki).

Answer 5

Nie widzę problemu z utrzymywaniem nieprawidłowych danych. To, co jest ważne lub nie, jest problemem biznesowym i czasami może zależeć od sytuacji. Baza danych nie dba o te reguły biznesowe.

Jeśli muszę wypełnić duży formularz online, a ostatni krok wymaga podania danych karty kredytowej i nie mam gotowej karty, będę musiał wyrzucić wszystkie te informacje i następnym razem wprowadź to ponownie (co nie nastąpi, ponieważ wolę pójść gdzie indziej).Chciałbym, aby ta aplikacja przechowywała informacje, które już przekazałem, a później mogę sprawić, by były funkcjonalne. Dopóki nie jest to prawidłowe, nie mogę zamawiać rzeczy online.