înțelegerea Ruby on Rails ActiveRecord Validations

datele sunt un lucru minunat, dar datele greșite pot fi foarte foarte rele. Din fericire, dacă sunteți un programator Ruby on Rails, aveți la dispoziție un API frumos de asistenți de validare ActiveRecord.

acest ghid este o explorare a validărilor ActiveRecord comune și nu atât de comune într-o anumită aplicație Ruby on Rails. Folositi-l pentru a ajuta la menținerea bazele de date fericit!

de ce să folosiți validări?

pentru a vă asigura că numai datele valide sunt salvate în baza de date. Pe lângă validarea clientside, validările la nivel de model oferă un strat suplimentar de securitate pentru toate câmpurile de formular dintr-o aplicație Ruby on Rails.

puteți oferi validări într-o varietate de niveluri, dar toate au punctele lor forte și punctele slabe.

• constrângeri de baze de date – constrângeri unice la nivel de bază de date permite nici câmpuri duplicat sau coloane, dacă aveți nevoie. Acest lucru poate merge mult mai adânc decât unicitatea. adică valori implicite, constrângeri non-nule, intervale etc…
• validarea din partea clientului-acestea sunt utile vizual și oferă o experiență mai bună a utilizatorului, dar sunt adesea mai nesigure. Aproape întotdeauna aș oferi un plan de rezervă folosind această abordare așa cum ar trebui.
• nivelul modelului (șine) – despre ce vorbim acum!
• nivelul controlerului ( șine) – tentant de utilizat, dar mai dificil de testat și întreținut. Este o convenție / cea mai bună practică pentru a vă menține controlorii cât mai ușori posibil.

când apare validarea?

direct din documentația ruby on rails:

există două tipuri de obiecte de înregistrare Active: cele care corespund unui rând din Baza de date și cele care nu. Când creați un obiect nou, de exemplu folosind new metoda, acel obiect nu aparține bazei de date încă. După ce apelați save la acel obiect, acesta va fi salvat în tabelul bazei de date corespunzătoare. Înregistrare activă utilizează new_record? metoda instanță pentru a determina dacă un obiect este deja în baza de date sau nu.

crearea unei noi clase de înregistrări Active ne oferă posibilitatea de a utiliza o metodănew_record? pentru a descoperi toate acestea.

class Article < ApplicationRecordend

în acest fel putem apăsarails console pentru a identifica procesul.

$ 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

de fapt, apelareasave este ceea ce îl angajează în baza de date și în spatele scenei creează instrucțiunile necesareSQL pentru a face acest lucru. Ca rezultat, validările sunt de obicei rulate înainte de a trimite date către baza de date în întregime.

următoarele metode envoke validări la utilizare:

• create
• create!
• save
• save!
• update
• update!

versiunile bang (de ex. save!) ridicați o excepție dacă înregistrarea este nevalidă. Versiunile non-bang nu: save șiupdate returnfalse șicreate returnează doar obiectul.

metodele care omit validările

folosind oricare dintre următoarele vor omite validările în întregime. Utilizați cu prudență datele valoroase!

• 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. Ajutoarele de validare sunt unul dintre acele lucruri care mă fac să mă simt cald și confortabil atunci când implementez o nouă aplicație în sălbăticie. Acest lucru oferă o mulțime de sprijin pentru o gamă largă de date pe care le pot colecta de la client-side.

fiecare ajutor acceptă o:on și:message opțiune. Aceste opțiuni definesc când trebuie executată validarea și ce mesaj trebuie adăugat la o colecțieerrors dacă nu reușește (le puteți utiliza pentru a ajuta la injectarea a ceea ce este greșit în vizualizările dvs., astfel încât utilizatorul să știe ce să schimbe/modifice).

există o mulțime de ajutoare de validare, mai jos sunt câteva dintre cele mai utilizate. Vă rugăm să consultați Ghidul privind validările de înregistrare activă pentru mai multe cazuri de utilizare.

confirmare

util pentru validarea când două câmpuri de text trebuie să aibă aceeași intrare. Gândiți-vă, de exemplu, la o confirmare prin e-mail.

class User < ApplicationRecord validates :email, confirmation: trueend

acum, în opinia dvs., puteți avea două câmpuri:

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

un lucru este că această validare funcționează numai dacă opțiunea presence este setată la true și în model.

deciUser modelul primește o actualizare:

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

excludere

dacă trebuie să rezervați cuvinte sau să vă asigurați că o anumită intrare este unică, utilizațiexclusion.

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

observați cum am folosit:message și aici. Acest lucru este furnizat tuturor asistenților de validare.

de asemenea, puteți utilizainclusion în mod opus. Consultați documentele pentru mai multe informații!

format

șirurile de formatare sunt uneori ideale pentru aplicația dvs. Puteți utiliza expresii regulate în validări pentru a modifica orice doriți.

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

lungime

îl folosesc tot timpul pentru a pune o constrângere asupra lungimii caracterului unui câmp dat.

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

nu ezitați să personalizați mesajele cu:message și aici. Următoarele sunt toate disponibile pentru a cârlig în a personaliza mesajul.

• wrong_length
• too_long

too_short

exemplu

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

prezență

acesta este probabil cel mai utilizat ajutor din geanta mea de scule. Prezența verifică dacă câmpurile nu sunt goale.

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

de asemenea, puteți testa existența unei asociații pe modele

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

pe modelul opus, puteți face același lucru cu o captură numită inverse_of

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

unicitate

poate vrei nume de utilizator unice în aplicația ta? Unicitatea ajută cu asta.

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

aceasta caută de faptUser tabelul pentru înregistrările existente pentru a determinauniqueness

puteți merge mai departe și limitauniqueness până la unscope.

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

validări condiționale

uneori trebuie să validați doar în anumite condiții. Puteți efectua condiționări folosind o abordare ca următoarea.

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

trebuie să grupați mai multe condiții? Puteți face asta

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

metode personalizate

uneori ajutoarele nu sunt suficiente și s-ar putea să aveți nevoie de ceva mai personalizat. Puteți crea propriile metode care fac unele validări vă rola-te.

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

notă aici validez această metodă folosind opțiunea:on care vă permite să determinați unde să inițializați validarea. În acest caz am ales :create.

puteți, de asemenea, cârlig înerrors colectare ca am să modifice ceea ce ieșiri pe partea de client, dacă aveți nevoie să. Nu avem :message pe metode personalizate în acest caz. Citiți mai multe despre erori.

cuvinte finale

sperăm că validările au deschis câteva idei pentru a vă face aplicația mai constrânsă (într-un mod bun). Utilizarea Ruby on Rails și toate fațetele sale permite ca datele sigure să intre în orice bază de date la alegere. De la jetoane CSRF la validări la nivel de bază de date, există modalități nesfârșite de a îmbunătăți aplicația dvs. poate rămâne calm cu privire la datele care vin.

ștecher nerușinat!

dacă ți-a plăcut această postare, am mai multe videoclipuri pe YouTube și aici pe blogul meu. Vrei mai mult conținut ca acesta în căsuța de e-mail? Abonați-vă la newsletter-ul meu și obțineți-l automat.

Check out cursul meu

doriți să învețe Ruby pe șine de la sol în sus? Check out cursul meu viitoare numit Hello Rails.