8

私たちのアプリケーションには、さまざまなレイヤーがあります。サービス層、DAO 層、およびアクション (Struts アプリケーション)。

データは、あるレイヤーから別のレイヤーに渡されます。

入力検証を理想的にどこに配置する必要がありますか?

ユーザーID、電話番号はUIから来ているとしましょう。これらは必須です。そのため、すでにクライアント側で検証を行っています。

さて、私の意見では、必要なのはそれだけです。他に検証すべき場所はありません。

しかし、私の同僚の 1 人は、クライアントが直接要求した場合はどうなるかを主張しています。したがって、アクションも追加する必要があります。

現在、Dao でも同様のメソッドが他のアクションで使用されており、検証が行われていません。

または、サービス層と言って、それは Web サービスとして公開されている可能性があるので、そこにも検証があります。

本質的に、彼は提案しています..私たちはどこでも検証を行う必要があります。これは私には意味がありません。レイヤー全体での複製。

これに対する理想的なアプローチは何ですか? 検証が単純なnullチェックまたは複雑な検証であるとします。

4

3 に答える 3

13

Pangea に同意します。クライアントとサービスのエンドポイントで必ず検証を行う必要があります。

検証の概念は「フェイルファスト」であることを付け加えておきます。各レイヤーに検証を追加して、トランザクションを開始したり、複雑なクエリを作成したり、フィールドが短すぎることを見つけるためだけに書き込みを行ったりする代わりに、呼び出しが失敗する理由についてユーザーまたは呼び出し元がすぐにフィードバックを得ることができるようにします。

クライアント側では、ユーザーの時間、帯域幅、およびサーバー側のリソース (多くの場合、競合が発生します) を無駄にしないように、できるだけ多くの検証が必要です。ただし、通常、クライアント側ですべての検証を行うことはできません (たとえば、サインアップ時にそのようなユーザー名が既に使用されているかどうかを確認するなど)。サービス層にヒットします。

サーバー層では、すべての入力が潜在的に危険で不正確であると想定する必要があります (多くの場合、そうなる可能性があります)。私は実際、サービス層での入力の検証をより包括的かつ積極的に行う方が良いと考えています。それが最後の防衛線だからです。クライアント側で 1 つまたは 2 つの検証を省略した場合、何が問題なのかをユーザーに知らせるための優れた障害処理メカニズムが必要になります。サービス側で何かを見逃して災害が発生した場合は、何時間または何日もかけてデバッグし、データベースのバックアップを復元しようとすることを意味する可能性があります。

参照整合性などを強制する、データベース レベルでも実行されるチェックがいくつかあります。さまざまな RDBMS のエラー メッセージを解釈し、それらをユーザーが理解できる専門用語に変換しようとすることは、不可能ではないにしても難しい場合が多いため、通常、書き込みを試みる前にできる限りチェックするようにします。

于 2011-01-31T08:56:56.210 に答える
5

アプリケーションが複数のエントリ ポイント (UI またはシステム間インターフェイスまたはバッチ システム) を提供する場合、これらすべてのエッジで、サービス レイヤーに到達する前にデータをクレンジング(ヌル チェック、フォーマット チェック、必要性など) する必要があります。ただし、これは、検証ロジックを複製する必要があるという意味ではありません。検証を一元化できるフレームワークを使用できます。いくつかの検証フレームワークの例は、この投稿にあります。

ただし、ドメイン層に属すべきビジネス検証があり、それらはドメイン サービス層またはドメイン オブジェクトに残す必要があります。

DAO で検証を実行する必要があることに同意しません。DAO は CRUD 操作のみを担当する必要があります。彼らがそれ以上のことをしている場合は、レイヤーが漏れています。バッチで処理する必要がある場合は、バッチも同じ検証を通過するように、バッチがサービス層を通過することを確認する必要があります。

于 2011-01-31T07:43:06.753 に答える
1

私が会話に加えることができる一つの知恵は、決してクライアントを信頼しないことです。クライアントがHTML、Flash / Flexなどのいずれであっても、誰かがそれをハッキングして、あなたが望まないことをしようとする可能性があります。ここでのフォローアップは、誰かがハッキングする可能性がある場合、ソフトウェアエンジニアはハッキングされると想定する必要があるため、フロントエンドのチェックは優れており、アプリケーションの使いやすさを向上させることができます。 、チェックが重複する場合でも、バックエンドですべての入力を検証する必要があります。

于 2011-01-31T15:31:47.430 に答える