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

Question

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

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

他にも同じように感じている人の投稿やブログを見つけましたが、Zendの開発者が理由でこの選択をしたし、他の人も問題なく使っているようですので、フィードバックをもらいたいと思いました。ここのコミュニティから。

私が言ったように、これは主にZendに当てはまりますが、Zendはできるだけ多く、または少なく使用できるように設計されているため、Zendフレームワークの範囲内で作業するのではなく、問題全体を見ることが重要だと思います。 、あなたが望むように。

Answer 1

アプリケーションに関連するデータ検証は、データベーススキーマに関連するデータ検証と常に同じであるとは限らないことを覚えておくことが重要です。

ユーザーがユーザー名とパスワードを使用してアカウントを作成する簡単な登録フォームについて考えてみます。パスワードをX文字の長さにし、文字タイプ（またはその他）を適切に組み合わせたいため、パスワードの検証を実行します。

ただし、プレーンテキストのパスワードは保存しないため、データベース挿入用のデータの検証には関係ありません。何らかの方法（md5、md5 + saltなど）でパスワードのハッシュを保存することになります。代わりに、32文字の16進文字列があることを確認して、適切に作成されたMD5ハッシュである可能性が非常に高い場合があります。

このパスワードの例だけがシナリオではありません。このトピックで説明するのに適したシナリオです。

それで、答えは何ですか？私は、1つの解決策がすべてに適合するとは思いません。場合によっては、データを2回検証する必要があります（必要ですか？）。モデルで1回だけ実行する場合があります。アプリケーションのニーズに可能な限り一致させてください。

Answer 2

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

さらに、モデルでの直接の検証は、まれにフォーム レンダリング システムに統合されていないため、エラー メッセージを表示し、ユーザーが入力したデータをフォームに再入力する場合に問題が発生します。

どちらのソリューションにも、それぞれ長所と短所があります。検証が最終的に何らかのレベルで行われなければならないことを保証するシステムがあれば完璧です. フォームが一部のデータを検証しない場合、モデルは検証し、その逆も同様です。残念ながら、そのようなライブラリのことは聞いたことがありませんが、フレームワークのバリデータは異常にソースに依存しないことに注意する必要があります。それらに POST データを渡すことができますが、適切に解析された CSV、MYSQL データベースなどから取得した情報でも同じことができます。

Answer 3

おそらく、Zend Framework の主任開発者の 1 人であるMatthew Weier O'PhinneyによるUsing Zend_Form in Your Models を参照して、まさにこの質問に対する彼の見解を確認してください。

Answer 4

Zendについては知りません。しかし。

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

モデル側でできる最善の方法は、すべてのデータに対して「アサーション」を呼び出して、開発時に検証が行われたことを確認することです。

コード (UI、モデル、ユーティリティ) のレベルが低いほど、検証とチェックのコードは少なくて済みます。そのため、同じ検証が複数回呼び出される可能性が高くなります。

Answer 5

ユーザー入力は、入力フォームに固有であるため、入力時に検証する必要があります (つまり、何らかのフォーム検証を行います。数値を入力する必要があるテキスト ボックスが数値であることを確認します)。

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

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

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

モデルまたはデータベースは、ユーザー コードが完全に間違ったこと (制約など) を行っていないことを確認するために、追加の検証を行う場合があります。

Answer 6

Peter Bailey のパスワードの例は優れています。ユーザー モデルは、パスワードが設定されている場合にのみ検証できますが (プレーン テキストではなくハッシュとして保存されるため)、入力の検証では、元のプレーン テキストのパスワードがセキュリティ要件 (文字数など) に対応していることを確認できます。 ）。したがって、モデルの検証とフォーム/入力の検証の両方が必要です。理想的には、肥大化したコントローラーアクションではなく、個別の再利用可能なコンポーネントとしてです。

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

無効なモデル データは常に例外をスローする必要があります (そうしないと、アプリケーションは間違いに気づかずに実行を継続できます)。一方、外部ソースからの無効な入力値は予期しないものではなく、よくあることです (決して間違いを犯さないユーザーがいる場合を除く)。

参照: https://lastzero.net/2015/11/form-validation-vs-model-validation/