zrozumienie walidacji Ruby on Rails ActiveRecord

dane to świetna rzecz, ale złe dane mogą być bardzo złe. Na szczęście, jeśli jesteś programistą Ruby on Rails, masz do dyspozycji ładne API pomocników walidacji ActiveRecord.

Ten przewodnik jest eksploracją powszechnych i nie tak powszechnych walidacji ActiveRecord w danej aplikacji Ruby on Rails. Użyj go, aby pomóc utrzymać bazy danych szczęśliwy!

po co używać walidacji?

aby upewnić się, że tylko poprawne dane są zapisywane w bazie danych. Oprócz walidacji po stronie klienta, walidacje na poziomie modelu zapewniają dodatkową warstwę bezpieczeństwa dla wszystkich pól formularzy w aplikacji Ruby on Rails.

możesz dostarczyć walidacje na różnych poziomach, ale wszystkie mają swoje mocne i słabe strony.

• ograniczenia bazy danych – unikalne ograniczenia na poziomie bazy danych nie pozwalają na duplikowanie pól lub kolumn, jeśli tego potrzebujesz. To może pójść znacznie głębiej niż tylko wyjątkowość. tzn. wartości domyślne, ograniczenia inne niż nil, zakresy, itd…
• Walidacja po stronie klienta-są one użyteczne wizualnie i zapewniają lepsze wrażenia użytkownika, ale często są bardziej zawodne. Prawie zawsze dostarczałbym Plan zapasowy, stosując takie podejście, jak należy.
• poziom modelu (Rails) – o czym teraz mówimy!
• poziom kontrolera (Rails) – kuszący w użyciu, ale trudniejszy do przetestowania i utrzymania. Jest to konwencja / najlepsza praktyka, aby utrzymać Kontrolery tak lekkie, jak to możliwe.

kiedy faktycznie następuje Walidacja?

prosto z dokumentacji ruby on rails:

istnieją dwa rodzaje obiektów aktywnego rekordu: te, które odpowiadają wierszowi w bazie danych i te, które nie. Podczas tworzenia nowego obiektu, na przykład przy pomocy metody new, obiekt ten nie należy jeszcze do bazy danych. Po wywołaniu save na tym obiekcie zostanie on zapisany do odpowiedniej tabeli bazy danych. Active Record używa metody instancjinew_record? do określenia, czy obiekt jest już w bazie danych, czy nie.

utworzenie nowej klasy Active Record daje nam możliwość użycia metodynew_record?, aby to wszystko zrozumieć.

class Article < ApplicationRecordend

w ten sposób możemy nacisnąćrails console, aby wskazać proces.

$ rails console>> article = Article.new(title: "My Article")=> #<Article id:nil title: "My Article", created_at: nil, updated_at: nil>>> article.new_record?=> true>> article.save=> true>> article.new_record?=> false

faktycznie wywołaniesave jest tym, co zatwierdza go do bazy danych i za kulisami tworzy niezbędneSQL instrukcje, aby to zrobić. W rezultacie walidacje są zazwyczaj uruchamiane przed całkowitym wysłaniem danych do bazy danych.

następujące metody sprawdzania poprawności przy użyciu:

• create
• create!
• save
• create!

savesave!

• update
• update!

wersje Bang (np. save!) zgłasza wyjątek, jeśli rekord jest nieprawidłowy. Wersje non-bang Nie: save Iupdate zwracafalse, Icreate po prostu zwraca obiekt.

metody pomijające walidacje

użycie którejkolwiek z poniższych metod całkowicie pominie walidacje. Używaj ostrożnie na cennych danych!

• decrement!
• decrement_counter
• increment!
• increment_counter
• toggle!
• touch
• update_all
• update_attribute
• update_column
• update_columns
• update_counters

Validation helpers

What I love about Ruby on Rails is the bundled goodness you get for doing pretty hard things. Pomocnicy walidacji to jedna z tych rzeczy, które sprawiają, że czuję się ciepło i przytulnie podczas wdrażania nowej aplikacji na wolności. Zapewnia to dużą obsługę szerokiego zakresu danych, które możesz zbierać po stronie klienta.

każdy helper akceptuje opcję :on I :message. Opcje te definiują, kiedy Walidacja powinna zostać uruchomiona i jaki komunikat powinien zostać dodany do kolekcji errors, jeśli nie powiedzie się (możesz użyć tych opcji, aby pomóc w wstrzyknięciu tego, co jest nie tak w Twoich widokach, aby użytkownik wiedział, co zmienić/zmienić).

Istnieje mnóstwo pomocników walidacji, poniżej są niektóre z moich najczęściej używanych. Więcej przypadków użycia znajdziesz w przewodniku dotyczącym walidacji rekordów aktywnych.

potwierdzenie

przydatne do walidacji, gdy dwa pola tekstowe muszą mieć ten sam wpis. Pomyśl na przykład o potwierdzeniu wiadomości e-mail.

class User < ApplicationRecord validates :email, confirmation: trueend

teraz w Twoim widoku możesz mieć dwa pola:

<%= text_field :user, :email %><%= text_field :user, :email_confirmation %>

jednym z nich jest to, że Walidacja ta wykonuje się tylko wtedy, gdy opcjapresence jest ustawiona na true również w modelu.

więcUser model otrzymuje aktualizację:

class User < ApplicationRecord validates :email, confirmation: true validates :email_confirmation, presence: true end

wykluczenie

Jeśli chcesz zarezerwować jakieś słowa lub upewnić się, że dany wpis jest unikalny, użyjexclusion.

class Profile < ApplicationRecord validates :username, exclusion: { in: %w(username1 username2 username3), message: "%{value} has already been taken." }end

zauważ, jak użyłem:message tutaj również. Jest to dostępne we wszystkich pomocnikach walidacji.

Możesz również użyć inclusion w przeciwny sposób. Zobacz dokumenty, aby uzyskać więcej informacji!

Format

ciągi formatowania są czasami idealne dla Twojej aplikacji. Możesz używać wyrażeń regularnych w walidacjach, aby zmieniać to, czego szukasz.

class Plan < ApplicationRecord validates :plan_type, format: { with: /\A+\z/, message: "Plans can only inlude letters"}end

Length

używam go cały czas, aby ograniczyć długość znaków danego pola.

class User < ApplicationRecord validates :name, length: { minimum: 5 } # sets a minimum validates :bio, length: { maximum: 500 } # sets a maximum validates :handle, length: { in: 5..16 } # provide a rangeend

Możesz spersonalizować wiadomości za pomocą:message również tutaj. Poniżej znajdują się wszystkie dostępne do podłączenia, aby dostosować wiadomość.

• wrong_length
• too_long
• too_short

przykład

class User < ApplicationRecord validates :bio, length: { maximum: 800, too_long: "%{count} characters is the maximum." }end

obecność

jest to prawdopodobnie najczęściej używany pomocnik w mojej torbie narzędziowej. Obecność sprawdza, czy pola nie są puste.

class User < ApplicationRecord validates :name, :email, presence: trueend

Możesz również przetestować istniejące skojarzenie na modelach

class Article < ApplicationRecord belongs_to :user validates :user, presence: true # looks for a user_id field on the articleend

na przeciwstawnym modelu możesz zrobić to samo z jednym haczykiem o nazwieinverse_of

class User < ApplicationRecord has_many :articles, inverse_of: :userend

wyjątkowość

może chcesz mieć unikalne nazwy użytkownika w swojej aplikacji? Pomaga w tym wyjątkowość.

class User < ApplicationRecord validates :username, uniqueness: true, { message: "Username already taken" }end

to faktycznie przeszukuje User tabela istniejących rekordów, aby określić uniqueness

możesz pójść dalej i ograniczyć uniqueness do scope.

class User < ApplicationRecord validates :plan, uniqueness: { scope: :year, message: "can only update one per year"}end

walidacje warunkowe

czasami wystarczy Walidacja w określonych warunkach. Możesz wykonywać warunki przy użyciu następującego podejścia.

class Purchase < ApplicationRecord validates :card_number, presence: true, if: :paid_with_card? def paid_with_card? payment_type == "card" endend

potrzebujesz grupować wiele warunków? Możesz to zrobić

class User < ApplicationRecord with_options if: :is_admin? do |admin| admin.validates :location, length: { minimum: 10 } admin.validates :job_title, presence: true endend

niestandardowe metody

czasami pomocnicy nie wystarczają i możesz potrzebować czegoś bardziej niestandardowego. Możesz tworzyć własne metody, które wykonują walidacje, które sam wykonujesz.

class Invoice < ApplicationRecord validate :active_subscriber, on: :create def active_customer errors.add(:customer_id, "is not active") unless subscriber.active? endend

Uwaga tutaj sprawdzam tę metodę za pomocą opcji:on, która pozwala określić, gdzie zainicjować walidację. W tym przypadku wybrałem :create.

Możesz również podłączyć do errors kolekcji, ponieważ muszę zmienić, jakie wyjścia po stronie klienta, jeśli potrzebujesz. W tym przypadku nie mamy :message na niestandardowych metodach. Przeczytaj więcej o błędach.

Ostatnie słowa

mam nadzieję, że walidacje otworzyły kilka pomysłów, aby Twoja aplikacja była bardziej ograniczona (w dobry sposób). Korzystanie z Ruby on Rails i wszystkich jego aspektów pozwala na Bezpieczne wprowadzanie danych do dowolnej wybranej bazy danych. Od tokenów CSRF do walidacji na poziomie bazy danych, istnieje nieskończona ilość sposobów na ulepszenie aplikacji, która może zachować spokój na temat napływających danych.

bezwstydna Wtyczka!

Jeśli podobał Ci się ten post, mam więcej filmów na YouTube i tutaj na moim blogu. Chcesz więcej takich treści w swojej skrzynce odbiorczej? Zapisz się do mojego newslettera i otrzymuj go automatycznie.

Sprawdź mój kurs

chcesz nauczyć się Ruby on Rails od podstaw? Sprawdź mój nadchodzący kurs o nazwie Hello Rails.