Ответ 1
Я очень рекомендую сделать это в обоих местах. Выполнение этой задачи в модели сохраняет запрос к базе данных (возможно, по всей сети), что по существу будет ошибкой, и выполнение этого в базе данных гарантирует согласованность данных.
Как правило, лучше (и почему) проверять атрибуты в модели или в определении базы данных?
Для (тривиального) примера:
В пользовательской модели:
validates_presence_of :name
в сравнении с миграцией:
t.string :name, :null => false
С одной стороны, включение его в базу данных кажется скорее гарантией от проникновения каких-либо плохих данных. С другой стороны, включение этой модели в модель делает вещи более прозрачными и более понятными, группируя их в код с остальными валидациями. Я также подумал о том, чтобы сделать то и другое, но это кажется не сухим и менее ремонтопригодным.
Я очень рекомендую сделать это в обоих местах. Выполнение этой задачи в модели сохраняет запрос к базе данных (возможно, по всей сети), что по существу будет ошибкой, и выполнение этого в базе данных гарантирует согласованность данных.
А также
validates_presence_of :name
не совпадает с
t.string :name, :null => false
Если вы просто установите столбец NOT NULL в своей БД, вы все равно можете вставить пустое значение (""). Если вы используете модель validates_presence_of - вы не можете.
Хорошая практика заключается в том, чтобы сделать то и другое. Проверка модели удобна для пользователей, в то время как проверка базы данных добавляет последний компонент курорта, который укрепляет ваш код и обнаруживает недостающие проверки в логике вашего приложения.
Это меняется. Я думаю, что простая, связанная с данными проверка (например, длина строк, ограничения полей и т.д.) Должна выполняться в базе данных. Любая проверка, которая следует за некоторыми бизнес-правилами, должна выполняться в модели.
Я бы рекомендовал проект Migration Validators (https://rubygems.org/gems/mv-core), чтобы определить валидацию на уровне db, а затем прозрачно продвинуть его в модели ActiveRecord.
Пример:
в миграции:
def change
create_table :posts do |t|
t.string :title, length: 1..30
end
end
в вашей модели:
class Post < ActiveRecord::Base
enforce_migration_validations
end
В результате вы получите проверку данных на два уровня. Первый будет реализован в db (как условие в триггере ограничения проверки), а второй - как проверка ActiveModel в вашей модели.
Зависит от дизайна вашего приложения, Если у вас есть приложение небольшого или среднего размера, вы можете сделать это как в модели, так и в модели, Но если у вас есть большое приложение, вероятно, его ориентированное на обслуживание или в слоях, то есть базовая валидация, то есть обязательная/нулевая, минимальная/максимальная длина и т.д. В базе данных и более строгие i.e паттеры или бизнес-правила в модели.