Nie jestem do końca pewien, czy jest to dobra decyzja projektowa, aby weryfikatory walidowały polecenia w oparciu o stan bazy danych. Na przykład, jeśli muszę sprawdzić poprawność komponentu User bean oprócz sprawdzenia, czy adres e-mail i nazwa użytkownika są puste itd. Muszę też odrzucić wartości, jeśli są już używane. Czy ten rodzaj logiki powinien być w walidatorach lub obiektach usług?Czy weryfikatorzy wiosną powinni uzyskać dostęp do bazy danych?
Cóż, weryfikatory są po prostu fasolką szparagową, tak, aby mogły zostać wstrzyknięte obiekty usługowe, które obsługują dostęp do danych. Możesz umożliwić walidatorom pobieranie danych z bazy danych bez naruszania projektu.
nie, weryfikatory IMHO powinny być małe i side-effect free, aby umożliwić ich łatwe łączenie. Ostatecznie walidator powinien zostać odłączony od warstwy trwałości.
sprawdziłem jeden z kopalni, a ja dzwonię warstwie usług z walidatora:
@Service
public final class StartFormValidator {
private FacilityService facilityService;
private AdminService adminService;
/**
* Verify that they've selected a facility. Verify that they've selected a
* valid facility. Verify that they've selected a view and that it's a valid
* view.
*
* @param startForm
* @param errors
* @return true if no errors were set
*/
public boolean isValid(final StartForm startForm, final Errors errors) {
if (startForm.getFacilityId() == 0) {
errors.rejectValue("facilityId", "facilityIdEmpty",
"Select a facility.");
}
if (!this.facilityService.isFacilWaitlistEnabled(startForm
.getFacilityId())) {
errors.rejectValue("facilityId", "facilityInvalid",
"Invalid facility");
}
if (StringUtils.isBlank(startForm.getPassword())) {
errors.rejectValue("password", "passwordEmpty",
"Enter the password.");
return (false);
}
if (!this.adminService.validateAdmin(startForm.getPassword()))
errors.rejectValue("password", "passwordInvalid",
"Incorrect password");
return (!errors.hasErrors());
}
/**
* @param _facilityService
*/
@Autowired
public void setFacilityService(final FacilityService _facilityService) {
this.facilityService = _facilityService;
}
/**
* @param _adminService
*/
@Autowired
public void setAdminService(final AdminService _adminService) {
this.adminService = _adminService;
}
}
To byłoby bardzo dużo zależy od sposobu zdefiniowania walidacji. Rozważ to: Kupujesz coś i wpisujesz numer swojej karty kredytowej. Jeśli cyfra kontrolna nie jest zgodna, nie udało się sprawdzić poprawności. Nie podjęto próby transakcji. Jeśli jednak jest to poprawny numer karty kredytowej, ale nie pasuje do Twojego kodu pocztowego (wymagana interakcja DB/Third Party), oznacza to błąd w płatności.
Rozważ teraz: Podajesz swój adres i wpisujesz Mastiffica jako swój kraj. Dlaczego system pozwolił ci na to? - Powinien był ograniczyć interfejs tylko do prawidłowych wpisów (brak DB wymaga wpisu).
Możesz też wpisać "pięćdziesiąt" w polu kwoty na ekranie płatności bankowych. Dlaczego dopuszcza tam listy - które nie sprawdzają poprawności (nie ma potrzeby stosowania DB). Ale wtedy wpisujesz 50 w polu kwoty i okazuje się, że nie masz 50 funtów na koncie. Czy to jest błąd sprawdzania poprawności? Czy jest to nieudana transakcja?
Teraz należy pamiętać o zaliczeniu wszystkich podstawowych weryfikacji wejść (suma kontrolna karty kredytowej, kraj, cyfry, kod pocztowy), a transakcja nie powiedzie się, ponieważ karta kredytowa wygasła. Czy to błąd sprawdzania poprawności, czy nieudana transakcja?
Możesz uznać walidację za podstawową gwarancję, że użytkownicy nie będą wprowadzać całkowicie dzikich danych, lub możesz pomyśleć o zatwierdzeniu jako "mogę zakończyć tę transakcję danymi, które dostałem". Osobiście faworyzowałbym tego pierwszego, ale znowu jest to kwestia definicji.
Potem jest aspekt walidacji pierwszej linii jako środek bezpieczeństwa - wild danych, które zostały zaakceptowane przeszłość swojej górnej warstwie UI może być zagrożenie bezpieczeństwa (SQL injection, eg)
Jeśli naprawdę wierzą w „MVC "wtedy nie sądzę, że chciałbyś, aby twoje walidatory trafiły do bazy danych. Walidacja to faza, która w istocie potwierdza dane z logiki biznesowej.
Baza danych nie musi być świadoma, w jaki sposób walidatory będą z niej korzystać, a weryfikatorzy nie powinni wiedzieć, jaka baza danych jest. To po prostu nie pasuje do modelu MVC. Jutro, jeśli masz dane pochodzące z wielu źródeł, czy mógłbyś kontynuować i powiedzieć swoim weryfikatorom, które źródło w konkretnym przypadku powinno uzyskać dostęp, pod jakimi warunkami. To samo będzie stanowić logikę, która nie jest nawet wymagana. w aplikacji.
Rodzaj sprawdzania, którego szukasz, zostanie przyjęty jako część obiektów biznesowych, co zagwarantuje, że przed wywołaniem obiektów usługi będą nawet wywoływane; taka kombinacja jeszcze nie istnieje.
Obiekty usługowe nie powinny również zawierać walidacji biznesowych, więc nie należy ich do walidatorów ani obiektów usługi. Ale tak, jeśli aplikacja jest wystarczająco mała, aby nie martwić się zbyt wieloma warstwami, skośne podejście jest w porządku, ale tylko tak długo, jak "jest przestrzegane jako standard w całym tekście".
Podsumowując, uważam, że weryfikatory sprężyn są przeznaczone do podstawowych walidacji, a nie do sprawdzania poprawności biznesowej.
Preferuję walidację, która korzysta z bazy danych, ponieważ jest użyteczna dla użytkownika końcowego.
Po przesłaniu formularza rejestracyjnego chcesz sprawdzić, czy nazwa użytkownika jest poprawna pod względem składni i czy ta nazwa użytkownika nie została jeszcze podana (wymagany dostęp do bazy danych).
Formularz może zwracać wszystkie błędy jednocześnie. Może pokazać użytkownikowi wszystkie problemy. Użytkownik może to naprawić i wysłać formularz ponownie.
Wiem, że możesz zrobić to mądrzej z ajaxem i tak dalej, nie o to chodzi.
Zawsze sprawdzam wszystko. Sprawdzam, czy ten formularz będzie obsługiwany przez nadchodzącą transakcję. Jeśli nie, otrzymuję wyjątek z powodu pewnego współbieżnego dostępu, który można łatwo obsłużyć.
Co robisz, gdy chcesz sprawdzić, czy odwołanie odnosi się do prawdziwego obiektu? Nie powinny zmieniać danych, ale czasami trzeba wykonać przynajmniej weryfikację identyfikatora. –
Słyszałem lub czytałem to wcześniej, właśnie dlatego zadaję to pytanie. Ale nie jestem do końca pewien, co powinienem zrobić, jeśli nie pozwolę im czytać z bazy danych (bez efektów ubocznych). Jestem trochę zmieszany w tym temacie, ponieważ wydaje się, że wiele osób w świecie Java dzieli się twoją opinią, podczas gdy w Django i RoR jest całkowicie normalne powiązanie sprawdzania poprawności z bazą danych. – Vasil
A gdzie dokładnie sprawdzasz, czy już podano nazwę użytkownika w formularzu rejestracyjnym? – Janning