2013-07-01 11 views
12

Wydaje się oficjalnym sposobem sprawdzania poprawności modeli w laravel 4 jest poprzez Validator w Controller? Czy ktoś może wskazać, dlaczego tak jest?laravel walidacji 4 vs modelu walidacji Controller

Czy nie byłoby bardziej sensowne wdrożenia walidacji w Model?

+1

Nie powiedziałbym oficjalnie. Jest to po prostu łatwiejszy sposób na pokazanie walidatora, ponieważ ustawienie odpowiedniej usługi sprawdzania poprawności jest nieco bardziej skomplikowane. Istnieje wiele przykładów tam, a także pakiety, które przeprowadzają walidację w samym modelu lub jako oddzielna usługa. Zajrzyj do tych. –

+4

Jedną z zalet sprawdzania poprawności modelu jest to, że sprawdzanie poprawności zostało również zatwierdzone. –

+1

Chciałbym powiedzieć oficjalnie, ponieważ jest to jedyny sposób sugerowany przez oficjalną dokumentację. Jeśli to nie jest oficjalne, co by to było? – igorsantos07

Odpowiedz

15

Wolę pakiet Ardent dokonywania walidacji modeli jako gładkie i minimalnych, jak to możliwe. Dla mnie bardziej sensowne jest posiadanie reguł walidacji również w modelu.

Zwróci wartość false, gdy zostanie wywołane $model->save(), a sprawdzanie poprawności nie powiedzie się, można na przykład uzyskać komunikaty o błędach za pośrednictwem $model->errors()->all().

+2

Czuje się dla mnie bardzo Laravel'ish: Użyj pakietu, który wykonuje dla ciebie całą ciężką pracę. –

+0

@NiklasModess Czy masz jakieś sugestie, w jaki sposób mogę użyć zarówno Ardent i inny pakiet, który używam, który rozszerza Eonquent, aby umożliwić ORM MongoDB? Mój model rozszerza model utworzony przez ten inny pakiet. – Thelonias

+0

@NiklasModess, czy znasz pakiet, który pozwoliłby moim modelom być zarówno modelami obciążonymi, jak i modelami MongoDB? – Thelonias

5

To ma sens mieć walidacji w modelach, ale walidacja powinna być tylko tam, aby upewnić się, że nie oszczędzają żadnych uszkodzonych danych.

Validator jest w Controller, ponieważ służy do obsługi wejścia i generowania danych wyjściowych. Jeśli chcesz dokonać sprawdzenia poprawności w Model, musisz albo zwrócić wartość false, i pokazać użytkownikowi najbardziej losowy komunikat o błędach dotyczących nieprawidłowych danych. Można również zwrócić kilka kine tablic zawierających wszystkie błędy, które są generowane, ale to jest coś, czego Model nie powinien robić. Lub możesz rzucić wyjątek, który jest czymś, co należy zrobić, gdy model próbuje wykorzystać nieprawidłowe dane, ale zabija aplikację, która nie jest pożądanym rozwiązaniem dla walidatora formularzy.

Podczas walidacji formularza w sterowniku, można zrobić wszystko, co chcesz z komunikatami o błędach, bez zmiany przeznaczenia modelu.

W modelu można wykonać sprawdzanie poprawności, aby upewnić się, że nie popełniono błędu, co spowoduje uszkodzenie bazy danych. Ponieważ w takim przypadku aplikacja powinna zostać zamknięta.

Tak więc w celu udzielenia odpowiedzi na to pytanie: Walidacja w modelu ma sens, aby uniknąć uszkodzenia danych, ale jeśli chcesz przekazać użytkownikowi opinię na temat nieprawidłowych danych wejściowych, powinien on znajdować się w kontrolerze.

+7

Myślę, że definiowanie reguł sprawdzania poprawności w jednym miejscu, a nie w wielu miejscach (model, kontroler, formularz front-end) jest tutaj kluczem. Model jest jedną wspólną rzeczą w tym scenariuszu. – Jason

+0

dlaczego "nie powinien" model zawiera własne komunikaty o błędach? jeśli myślisz o modelach jako obwolutach dla twojego DB, kiedy spróbujesz wstawić nieprawidłowe dane do twojego DB SQL dostarczysz z powrotem komunikat o błędzie, komu może nie pozwolić, żeby modele też to zrobiły? –

2

Walczyłem z tym przez chwilę i zdecydowałem się na obsługę większości moich walidacji w usłudze walidacji, opartej na czymś podobnym do linii this. Mogę wtedy mieć różne reguły sprawdzania poprawności w zależności od kontekstu.

Jak wspomina Nico, walidacja w modelu jest dobry, aby uniknąć utraty danych, ale wolę cienkie kontrolerów więc mijam funkcjonalności, które siedzą w kontrolerze do służby. Ma to również tę zaletę, że może ponownie wykorzystać walidację w różnych kontrolerach/metodach.

0

Dlaczego wolę In-model walidacji: Pracowałem z obu stylach i każdy ma plusy i minusy, ale wolę walidacji modelu. W naszej obecnej aplikacji nie widzę opcji sprawdzania przez kontroler jako opcji, ponieważ zmieniamy nasze dane w wielu miejscach (formularze dedykowane, edycja bezpośrednia, edycja zbiorcza, przesyłanie zbiorcze, api itp.). Nigdy tak naprawdę nie pracowałem z usługami walidacji (choć mogą to być opcje), ale ja osobiście lubię logikę utrzymywać jak najbliżej modelu, w ten sposób wiem, że inny programista nie obejdzie go. Nie lubię też dodawać mnóstwa dodatkowych plików na MVC i podstawowych folderach Libraries, ponieważ wydaje się, że musisz myśleć o prawidłowym organizowaniu.

Problemy z weryfikacją w modelu: Oto kilka rzeczy, które należy wziąć pod uwagę, aby dobrze funkcjonować w modelu. NIEKTÓRE Z TEJ JUŻ ZOSTAŁY PODJĘTE DO ROZWAŻENIA ZA POMOCĄ WTYKÓW. Myślę, że inne frameworki (CakePHP) już sobie z tym radzą, ale Laravel tak naprawdę nie.

  1. Wartości, które zostaną zweryfikowane, ale nie zapisane w bazie danych (np. "accept_agreement").
  2. wiele do wielu lub należy do wielu relacji
  3. Ustawienie domyślne warunkowy (nie krytyczne, ale może warto pomyśleć o tym samym czasie)
  4. różnych scenariuszy Form - czasami może trzeba inny walidacji zależności od których formularz je przesyła. Odwołanie do formularza może być atrybutem możliwym do wyczyszczenia o wartości .
  5. Jak odzyskasz komunikaty o błędach (wszystkie wtyczki walidujące w modelu obsługują to)
  6. Różne zestawy reguł sprawdzania poprawności. Twórcze kreacje kontra "prawdziwe" kreacje. (Większość obsłużyć to dla ciebie)

Ostatecznie, dla prostych aplikacji, które nie mają wiele sposobów interakcji z modelem, powiedziałbym walidacja kontroler może być prostsze, inne następnie, że wolę w -Model.