5

ユーザーに名前、カテゴリ リストを要求するアプリケーションがあるとします。ユーザーが保存ボタンをクリックすると、アプリケーションは名前とカテゴリをデータベースに保存します。

UI から名前とカテゴリを取得するレイヤーがあります。このレイヤーは、名前 (長さ > 0 の文字列) があるかどうかを確認します。これが正しければ、カテゴリ名を別のレイヤーに渡します。注: カテゴリは、常に 1 つの項目が選択されているラジオボタン リストです。

この 2 番目のレイヤーでは、アプリケーションはカテゴリに応じて、名前を保存する適切なクラスを選択します。

最後のレイヤーでは、クラスはこの名前をデータベースに保存します。このクラスでは、名前が空かどうかを確認します。

私の質問は、メソッドの入力パラメーターを確認する適切な場所はどこですか? すべてのレイヤーで？たぶん、これらのレイヤーを他の開発で使用するつもりです。

私の例は正しいですか？たぶん、データベース層に検証を残して、UI 層に例外を発生させることができます。

4

4 に答える 4

3

一般に、最終的に永続化される入力の検証に関するより大きな問題に関しては、次のことを行うのが最善です。

  • 入力パラメーターを受け取ったら、できるだけ早く完全にカプセル化されたビジネス・オブジェクトに変換してください。

  • 早期に検証してすぐに失敗し、下位レイヤーに到達するまで待ちます-リソースの無駄、時間の無駄、おそらくより複雑な（ロールバックするものが増える）.

  • ビジネス ロジックを一度検証し、その部分をオブジェクトのインスタンス化プロセスに含めます。(ただし、ビュー ロジックと永続化ロジックの検証は、他のレイヤーで実行する必要がある場合があり、ビジネス ロジックとは別であることに注意してください)

  • ORM (Hibernate など) を使用してオブジェクトを永続化する方法をモデル化して、メモリ内のオブジェクト レベルで純粋に作業し、永続化を実装の詳細として残すことができるようにします。ビジネス ロジックをオブジェクト レイヤーに集中させます。

また、メソッドの検証自体に関しては、すべてのレイヤーで Oded に同意し、メソッドのエントリ時にすぐに実行する必要があります。繰り返しますが、これはフェイル ファスト手法の一部です。ただし、上で述べたように、これはすべてのメソッド (またはすべてのレイヤー) でビジネス ロジックを検証するという意味ではありません。入力を検証する基本的な方法 (アサーションまたは明示的なチェックとスローされた例外のいずれか) について言及しているだけです。

于 2011-02-27T15:36:05.447 に答える
2

私は常に、すべてのレイヤーに関する推奨事項に同意しません。私にはあまりにも独断的に聞こえます。

すべてのデザインは、機能性とコストの間の選択を表しています。検証の選択もそれを反映する必要があります。

レイヤーの共有と再利用を考慮して決定する必要があると思います。

データベースが複数のアプリケーションによって共有されている場合、データベースはすべてのアプリケーションが適切に検証されることに依存することはできません。その場合、データベースはそれ自体を保護するために検証する必要があります。

この SQL インジェクション攻撃の時代では、永続化層に到達する前にバインディングと検証を行うことが必須だと思います。スキーマは、参照とビジネスの整合性を確保するために必要なこと (例: 列に対する一意の制約と「not null」が必要) を行う必要がありますが、データベースにアクセスする前に他の検証を行う必要があります。

データベースが 1 つのアプリケーションによって完全に所有されており、データへの唯一のゲートウェイであるサービスがある場合、そのサービスによって検証を行うことができます。データベース層で検証を複製するコストを免除できます。

UI とサービス層の間も同様です。

サービスはサービス指向アーキテクチャで多くのクライアントによって共有されるため、クライアント層とサービス層での二重検証が一般的です。現在、サービスはブラウザ ベースの UI で使用される場合があります。突然、サービスを要求するモバイル アプリの群れも出現します。その場合、サービスはすべてのリクエストを検証してバインドする必要があります。

すべての表面を鏡のように磨くメーカーはありません。研削と研磨の利点が無視でき、コストが高すぎるため、粗い鋳造面が許容される場合があります。

ソフトウェアも同様。

私は独断的な発言は好きではありません。選択の意味を理解しておくことをお勧めします。規則を理解し、規則を破るのが適切な場合を理解します。

于 2011-02-27T15:48:28.537 に答える
2

メソッドの入力パラメータを確認する適切な場所はどこですか? すべてのレイヤーで？

はい、すべてのレイヤーで。これは多層防御と呼ばれます。

各レイヤーでこれを行う理由はさまざまです。

  • UI/クライアント コード: 応答性を維持し、データが無効な場合のラウンドトリップを回避します
  • ビジネス層: ビジネス ルールが確実に守られるようにする
  • データ層: 有効なデータが渡されることを確認する
于 2011-02-27T15:35:49.650 に答える
0

他のアプリケーションもこれらの同じレイヤーを使用する非常に疎結合を行う場合は、すべてのステップで入力チェックを行うことをお勧めします。各クラス/メソッドは、スタック内でそれらの前に実行された他のクラス/メソッドの期待値を認識してはならないため、それぞれがその要件を個別に適用する必要があります。

  • ボタンがクリックされたときに値がテキスト ボックスにあることを UI が要求する場合は、それに応じて検証する必要があります。
  • ビジネス ロジックで、名前が null/空にならないようにする必要がある場合は、null/空の値をそのプロパティに配置することを許可しないでください。
  • データ層がそのフィールドに値の存在を要求する制約を持っている場合、データを永続化する前に値が存在することを確認する必要があります。
于 2011-02-27T15:39:18.043 に答える