改革の宝石は、モデル内で検証を行わないことを提唱しています。代わりに、フォームにあることを推奨します。
モデルからの検証
...
モデルにバリデーションを保持している場合 (これはすべきではありません)、それらをフォームにコピーするのが適切でないと感じる場合があります。その場合、Reform に自動的にコピーさせることができます。
...
検証をコピーすることは推奨されていないことに注意してください。検証コードをフォームに移動し、モデルを直接操作しないようにする必要があります。
モデルに検証がないことについて、reform gem プロジェクトまたはその作成者はどのような根拠を示していますか?
検証を 2 つの異なるカテゴリに分割します。
データの整合性とは、特定の基準を満たさないとモデルを使用できないことを意味します。この状態でモデルが有効と見なされないようにする必要があります。ただし、ほとんどの場合、これは永続性に関連する単一性などに関係しています。したがって、これらの制約は、モデルではなくデータベース レベルで適用することをお勧めします。
一方、ビジネス ロジックは、アプリケーションの機能上のニーズに直接関係しています。
例を見てみましょう: ユーザーがサインアップするとき、私は彼に電子メールのみを入力してもらいたいのですが、プロファイルを編集するときは、姓と名も入力するようにしたいと考えています。
検証がモデルに属していることを考慮すると、条件付き検証でモデルを混乱させる必要があります。ここでは、モデルがすでに永続化されているかどうかを検証する前に確認し、これでうまくいきます。しかし、要件が異なるフォームをさらに追加すると、すぐに管理が大変になります。
これは、検証ロジックがアプリケーションのコンテキスト (ユーザーが入力するフォーム、呼び出される API エンドポイントなど) に依存するためです。モデルの状態ではなく、このアプリケーション コンテキストに必要なパラメーターが有効であることを検証します。
コンテキストごとに異なる検証セットを設定すると、物事がはるかに簡単になり、保守しやすくなります。これにより、記述するコードが少し増えますが、よりクリーンで保守しやすいロジックになります。