0

Zend Framework と jQuery を使用して MVC アプリケーションを開発しています。私のモデルは、サービス層、マッパー、ドメイン モデルの 3 つの層で構成されています。

今日まで、私は入力の検証に苦労してきました。クライアントで発生するものもあれば、Zend フォームで発生するものもあれば、ドメイン モデルで発生するものもあります。責任が紛らわしくなっており、多くの重複したロジックがあります。

少し考えてみたところ、Zend フォームの検証をスキップしない理由がわかりません。JavaScript を使用して単純なもの (正規表現を含む) を検証し、必要に応じて (ajax を介して) サーバーから追加データを取得できます。フォームが検証に合格したら、それをサーバーに渡します。

もちろん、私のドメイン モデル ロジックは包括的である必要があります (クライアント上にあるものすべてを複製する) が、ドメイン モデルは他に何のためにあるのでしょうか?

何か不足していますか？注意すべき落とし穴はありますか？

編集：明確にするために、サーバー側の検証を放棄することをまったく提案していません。(これが必須であることは理解しています。) 私のドメイン モデルでそれができるのであれば、フォームでもそれを行う必要はないことを提案しています。

4

3 に答える 3

1

いいえ。誰でもクライアント側の Javascript を変更して、クライアント側のコードに必要なものを送信させることができます。このため、サーバーは、クライアントが送信するものを (検証せずに) 信頼しないという態度を取る必要があります。クライアント側の検証は、セキュリティのためにも、データの整合性を保護するためにも存在しません。クライアント側の検証は、ユーザー エクスペリエンスを向上させるためだけに存在します。クライアント側の検証を使用すると、Web サイトはサーバーを往復することなくユーザーにエラーを通知できるため、ユーザーが完了しようとしているタスクの負担が軽減されます。

于 2013-06-28T04:39:25.870 に答える
0

Zend/php固有の質問ですか? はいの場合、私の答えは当てはまらない可能性があります。

あなたが直面している問題は、検証ロジックの乗算であるようです。したがって、サーバー側では、1 か所だけで検証を強調する必要があり、それがドメイン モデルです。長所は次のとおりです。

長所：

  • 追跡が容易で、ルールはドメイン モデルに直接適用されます
  • ドメイン モデルには検証機能があるため、オブジェクトにアクセスするすべてのクラスが検証を実行できます。
  • ドメイン モデルが変更された場合は、検証も変更する方が自然です。

短所：

  • 再利用不可。特に継承とインターフェースがある OOP では、同様の構造を持つ他のドメイン モデル (おそらく派生クラス) に対して検証を使用することはできません。ただし、このケースは php には当てはまらない場合があります。
  • 柔軟性のない検証ロジック。異なる状態の同じオブジェクトに対して異なる検証ルールが必要になります。たとえば、リクエストを保存する場合、検証は下書き (一部のフィールドが空である可能性があります) とは異なり、公開され、完了または廃止される可能性があります。

目的：

通常、ドメインモデルではなく、検証を担当する特定のクラスを作成して検証を行います。再利用可能で柔軟性があるため、両方の短所を解決できます (DraftValidator、PublishedValidator を使用できます)。検証結果は、エラー メッセージやisValidプロパティなど、非常に一般的なものになる場合があります。

Javascript での検証:

サーバーへの要求/応答トリップを待つのではなく、特にユーザーに応答フィードバックを提供するために、JavaScript レベルで検証することは問題ありません。

于 2013-06-28T07:22:30.027 に答える