【Rails】バリデーションについて

 

バリデーションの概要

 

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」などの存在しないメールアドレスまで登録できるようになってしまう。

 

そのため、「正しいデータをデータベースに保存するため」にもバリデーションをかける必要がある。

 

 

また、バリデーションはモデル以外にも「コントローラー」「データベース制約」「クライアントサイド(JavaScriptSwiftなど)」でも実行可能だが、これらのレベルでバリデーションをかけると以下のようなデメリットがある。

 

 

コントローラーレベルのバリデーション

コードの記述量が増えてくると大抵の場合、手に負えなくなり、テストや保守が困難になりやすい。よってコントローラーレベルのバリデーションに頼るとアプリケーションの寿命を短くしてしまう。

 

データベース制約

バリデーションのメカニズムがデータベースに依存してしまい、これもコントローラーレベルのバリデーションと同じく、テストや保守が面倒になる。

但し、Rails以外のアプリケーションからもデータベース操作をする際はある程度のバリデーションをおこなっていた方が良いだろう。

 

クライアントサイドのバリデーション

クライアントサイドでバリデーションをかけるのは信頼性に欠ける。かく言うのもJavaScriptの場合、各種ブラウザでユーザーがJavaScriptをオフにしてしまえばいくらでもバリデーションを突破できてしまうからだ。なのでクライアントサイドのみでバリデーションをおこなうのは大変危険である。

 

 

よって、ほとんどの場合モデルレベルでバリデーションをおこなうことが最も適切である。

 

 

RubyとRailsの関連記事
  • 【全て公開】Railsエンジニアが入社6ヶ月で使ったRubyGems 4選
  • 【3時間で完成!?】Railsを使ってWebアプリを高速で作る方法
  • Rubyエンジニアはオワコンなのか?
  • Docker × Railsで日本時間を設定する方法
  • 【Rails】バリデーションについて
  • 【超カッコいい!】Ruby Gemの名前 3選!