フォームオブジェクトまたはモデルで検証を行う必要がありますか？

Question

この質問は主にPHPのZendを対象としていますが、他の言語やフレームワークにも当てはまりますので、皆さんの意見を歓迎します。

私はごく最近Zendのフレームワークを使用してきた、そしてそれは完璧ではないのですが、私はそれでかなり良い時間を過ごしてきました。しかし、私を夢中にさせることの1つは、Zendを使用する人々のほとんどの例が、モデルではなくv alidation in special form objectsです。フォーム入力以外の方法でデータがシステムに入力される可能性があるので、これは悪い習慣だと思います。他の入力を検証するためにバリデーターを曲げたりねじったり、検証を2番目に実行したり、ロジックを複製したりする必要があります。

私と同じような気持ちがある人もいますが、Zendの開発者が理由を挙げてこの選択をしてくれて、他の人が問題なく使っているようですここからコミュニティからのフィードバックを得ることができます。

私が言ったように、これは主にZendに当てはまりますが、Zendフレームワークの枠内で作業するのではなく、問題を全体として見ることが重要だと思います.Zendは、 、またはあなたが望むように、少しだけ。

Answer 1

これは非ゼンマイの答えですが、私はそのモデルが自分のデータの妥当性を担うべきだと考えています。この場合、検証はモデルに属しますが、これは必ずしも達成可能ではない可能性があり、ビューで検証を実行する必要があるかもしれませんが、モデルで実行された検証に加えて、それのための。

ビューでのみ検証が行われるという問題は、ある時点でデータの別のビューが必要になることがあることです。あなたのサイトは人気が高く、顧客は独自のビューを生成するためにXMLベースのAPIを求めています。データを検証するために顧客に頼っていますか？

APIを提供する必要がない場合でも、完全に異なるバージョンのページを保証するのに十分なカスタマイズされたビューが必要な場合があります。

あなたのモデルに検証を実行させることですが、検証結果が表示され、検証結果が表示されたページをもう一度読み込んでレンダリングできるようにすることが望ましいと思います。

ユーザーに検証データを即時に表示したいが、データの有効性に関する最終決定はモデルに任せておく必要がある場合は、ビューに検証を実行させることは完全に合理的だと思います。

Answer 2

私はZendを認識していません。しかし。

あなたのモデルは有効なデータを受け取る必要があります。モデルとそれのメソッドは何度も何度もデータをチェックすべきではありません。もちろん、実際のバリデーションを行う関数が存在する必要があり、guiの検証や他のデータ入力場所から呼び出される必要があります。

あなたは、モデルの側にできる最善のは、検証が行われていること、開発期間の確認するために、すべてのデータの「アサーション」と呼んでいます。

コード（UI、モデル、utilsの）以下の検証の低いレベル及びチェックコードが存在するべきです。その時、同じ妥当性検査が複数の検査と呼ばれる大きな可能性があります。

Answer 3

まあ、検証は多くの異なるレベルで行うことができ、通常はそれらのどれも「最高」ではありません。もちろん、モデルにはフォームから来ていない無効なデータを入れることができますが、データがどのモデルにも渡されないフォームを作成することもできます。

また、モデルでの直接検証はunsually我々はエラーメッセージを表示し、ユーザが入力したデータを使用してフォームを再移入したい場合は、問題が発生し、当社のフォームのレンダリングシステムと統合されていません。

両方のソリューションにはそれぞれ独自の賛否両論があります。検証が最終的にあるレベルで行われなければならないことを私たちに保証するシステムを持つことは完璧です。フォームがいくつかのデータを検証しない場合、モデルはその逆を行います。残念ながら、私はそのようなライブラリについては聞いていませんが、フレームワーク内のバリデーターは無関係にソースに依存しないことに注意する必要があります。 POSTデータを渡すことはできますが、正しく解析されたCSV、MYSQLデータベースなどから取得した情報でも同じことができます。

Answer 4

アプリケーションに関連するデータ検証は、データベーススキーマに関連するデータ検証と常に同じです。

は、ユーザーがユーザー名とパスワードでアカウントを作成し、簡単な登録フォームを考えてみましょう。パスワードの長さがX文字で、文字の種類が混在していればよいので、パスワードの検証を実行します。

しかし、平文のパスワードを保存しないため、データベースの挿入のためのデータを検証することは関係ありません。何らかの方法でそれらのハッシュを保存する予定です（md5、md5 + salt 、 なんでも）。代わりに、適切に作成されたMD5ハッシュである可能性が高いように、32文字の16進文字列を使用するようにしてください。

このパスワードの例は唯一のシナリオではありません。

答えはなんですか？私には解決策がないとは思わない。場合によっては、データを2回検証する必要があります（必要？）。時にはモデルでのみ一度だけ行うこともあります。できるだけアプリケーションのニーズに合わせてください。

Answer 5

フォームでの審美的な検証と、モデルでのビジネスルールの検証についてはどうでしょうか。

たとえば、登録用紙をお持ちください。

フォームは、電子メールフィールドがトリムされ、有効な電子メール、パスワード/確認パスワードフィールドが同一であること、およびユーザーが「同意する」チェックボックスを選択したことを確認します。

登録モデルは、電子メールがまだテーブルに格納されていないことを確認し、パスワードを暗号化してハッシュします。

私は通常2つを分割します。

Answer 6

おそらく、この質問に関する彼の見解では、Using Zend_Form in Your Models（Matthew Weier O'Phinney - Zend Frameworkのリード開発者の1人）を見てください。

Answer 7

ユーザー入力は、入力フォームに固有のものであるため入力されたときに検証する必要があります（つまり、フォームの検証を行う - 数値を持つ必要があるテキストボックスが数字であることを確認してください）。

ビジネスロジックは、モデル固有のものである（つまり、同じ部屋を既に予約していないことを確認してください）ため、おそらくモデルで検証する必要があります。

モデルレベルで検証する際の問題は、モデルをさまざまな方法で使用できることです。あるシナリオの正しい入力は、別のシナリオの入力が正しくない可能性があります。

もう1つの問題は、通常、不正な入力があるフォームコントロールの周囲に赤色のボックスを表示するなど、状況依存の検証が必要なことです。

モデルやデータベースでは、ユーザーコードが完全に間違ったこと（制約など）を行っていないことを確認するために、いくつかの追加検証が行われることがあります。

Answer 8

Peter Baileyのパスワードの例は優れています。入力検証が保証されている間にパスワードが設定されている（プレーンテキストとして保存されているのではなくハッシュとして）ため、ユーザーモデルは検証することができ、オリジナルのプレーンテキストパスワードはセキュリティ要件（文字数... ）。したがって、モデルの検証とフォーム/入力の検証は、理想的には別々の再利用可能なコンポーネントであり、膨大なコントローラのアクションでは直接行う必要はありません。

入力検証をホワイトリスト検証（「既知の良品」）とモデル検証をブラックリスト検証（「既知の不良を拒否する」）と考えてください。ホワイトリストの検証はブラックリストの検証によってモデル層が非常に特定のユースケースに過度に制約されることを防ぎますが、より安全です。

外部ソースからの無効な入力値が予期しないものではなく、むしろ一般的です（間違っていることがわからないユーザーがいない限り、モデルデータが例外をスローする原因となります。間違い）。

も参照してください。https://lastzero.net/2015/11/form-validation-vs-model-validation/