バリデーションの概要
class Person < ApplicationRecord
validates :name, presence: true
end
・
・
・
Person.create(name: "John Doe").valid? # => true
Person.create(name: nil).valid? # => false
このようにバリデーションをおこなうことで2つ目のPersonはデータベースに保存されない
バリデーションをおこなう理由
バリデーションは「正しいデータをデータベースに保存するため」におこなわれる。
例えば自分のアプリケーションの全てのユーザーには「メールアドレス」が必要だとする。
これをバリデーションをおこなわずに登録できてしまう場合、「aaaa@aaaa」や「aaa@gmall.con」などの存在しないメールアドレスまで登録できるようになってしまう。
そのため、「正しいデータをデータベースに保存するため」にもバリデーションをかける必要がある。
また、バリデーションはモデル以外にも「コントローラー」「データベース制約」「クライアントサイド（JavaScriptやSwiftなど）」でも実行可能だが、これらのレベルでバリデーションをかけると以下のようなデメリットがある。
コントローラーレベルのバリデーション →
コードの記述量が増えてくると大抵の場合、手に負えなくなり、テストや保守が困難になりやすい。よってコントローラーレベルのバリデーションに頼るとアプリケーションの寿命を短くしてしまう。
データベース制約 →
バリデーションのメカニズムがデータベースに依存してしまい、これもコントローラーレベルのバリデーションと同じく、テストや保守が面倒になる。
但し、Rails以外のアプリケーションからもデータベース操作をする際はある程度のバリデーションをおこなっていた方が良いだろう。
クライアントサイドのバリデーション →
クライアントサイドでバリデーションをかけるのは信頼性に欠ける。かく言うのもJavaScriptの場合、各種ブラウザでユーザーがJavaScriptをオフにしてしまえばいくらでもバリデーションを突破できてしまうからだ。なのでクライアントサイドのみでバリデーションをおこなうのは大変危険である。
よって、ほとんどの場合モデルレベルでバリデーションをおこなうことが最も適切である。
