2010-03-02 8 views
37

Czy ogólnie lepszym sposobem (i dlaczego) jest weryfikacja atrybutów w modelu lub definicji bazy danych?Ruby on Rails: Czy lepiej jest sprawdzić w modelu lub w bazie danych?

Dla (trywialny) Przykład:

W modelu użytkownika:

validates_presence_of :name 

porównaniu do migracji:

t.string :name, :null => false 

Z jednej strony, włączając go w wydaje się, że baza danych większa gwarancja na skradanie jakichkolwiek złych danych. Z drugiej strony uwzględnienie go w modelu sprawia, że ​​rzeczy stają się bardziej przejrzyste i łatwiejsze do zrozumienia poprzez zgrupowanie go w kodzie z resztą f zatwierdzenia. Rozważyłem także robienie obu, ale wydaje się to zarówno nie-SUCHEGO, jak i mniej konserwowalnego.

Odpowiedz

45

Gorąco polecam robienie tego w obu miejscach. Wykonanie tego w modelu powoduje zapisanie zapytania do bazy danych (prawdopodobnie w całej sieci), które zasadniczo spowoduje błąd, a wykonanie go w bazie danych gwarantuje spójność danych.

+1

Uderzyłeś mnie do tego przez 20 sekund;) – Aurril

+4

Zgadzam się z potwierdzeniem ograniczeń w obu miejscach (używam PostgreSQL i wtyczki sexy_pg_constraints http://github.com/maxim/sexy_pg_constraints), ale to nie jest do końca prawda sprawdzanie poprawności twoich modeli zapisuje zapytanie DB. Na przykład 'validates_uniqueness_of' musi wykonać zapytanie DB. –

4

Dobrą praktyką jest robienie obu. Walidacja modelu jest przyjazna dla użytkownika, a sprawdzanie poprawności bazy danych dodaje składnik ostatniej instancji, który powoduje utrwalenie kodu i ujawnia brakujące wartości w logice aplikacji.

2

To się zmienia. Myślę, że proste, związane z danymi sprawdzanie poprawności (takie jak długości łańcuchów, ograniczenia pola, itp.) Powinno być wykonane w bazie danych. Każda walidacja zgodna z niektórymi regułami biznesowymi powinna być wykonana w modelu.

0

Zależy od projektowania aplikacji, Jeśli masz aplikację małych lub średnich Można to zrobić to w obu lub tylko w modelu Ale jeśli masz dużą aplikację prawdopodobnie jego Service Oriented lub w warstwach wtedy podstawowy sprawdzanie poprawności tj. obowiązkowe/zerowalne, min/max długość itd. w bazie danych i bardziej rygorystyczne, tj. wzorce lub reguły biznesowe w modelu.

11

A także

validates_presence_of :name 
nie

to samo

t.string :name, :null => false 

Jeśli wystarczy ustawić NOT NULL w kolumnie DB nadal można wstawić pustą wartość (""). Jeśli używasz modelu validates_presence_of - nie możesz.

+1

Dobry połów, dzięki. Czy oślepnę, czy naprawdę nie ma żadnych wcześniej sprawdzonych poprawności, aby wprowadzić logikę modelu, aby dopasować się do logiki bazy danych, tak jak wszyscy zalecali? –

1

Polecam projekt Migration Validators (https://rubygems.org/gems/mv-core), aby zdefiniować sprawdzanie poprawności na poziomie db, a następnie w przejrzysty sposób promować go w modelu ActiveRecord.

Przykład:

migracji:

def change 
    create_table :posts do |t| 
    t.string :title, length: 1..30 
    end 
end 

w modelu:

class Post < ActiveRecord::Base 
    enforce_migration_validations 
end 

w wyniku trzeba będzie sprawdzanie poprawności danych dwupoziomowa. Pierwszy zostanie zaimplementowany w db (jako warunek w wyzwalaczu ograniczenia sprawdzającego), a drugi jako walidacja ActiveModel w twoim modelu.

Powiązane problemy