インターフェイス (コントラクト) とそれらの具体的な実装 (データ モデルとリポジトリの両方) を開発するとき、検証ロジックをどこに置くべきか疑問に思うことがあります。私の一部 (勝つ傾向がある) は、クラス自体が独自の検証 (文字列の最大長、日付バッファーなど) を担当する必要があると述べていますが、別の部分は、依存しているため、これをリポジトリに移動する必要があると述べています。永続ストアでは、これらの値はリポジトリの実装に基づいて変更される可能性があります。
クラスレベルで行わなければならない検証がいくつかあると思います。おそらくまとめて保持し、リポジトリが変更されても変更しないようにする必要があると思います。そのため、クラスに保持する傾向があります。
私はすべて UI 検証を入れようとしていますが、UI 検証の多くはバイパスできるため、これだけでは十分ではありません。
人々が何を考え、その背後にある理由に興味があります。
検証ロジックはどこに実装する必要がありますか?
どこにでも。
多くの作業や余分なオーバーヘッドのように見えるかもしれませんが、現実には、チェーンに沿ってすべてを再検証する十分な理由があり、そのうちの少なくとも 1 つは、問題になる前にバグをキャッチすることです。
-アダム
検証規則は、1) クラスのネイティブ環境で実行でき、2) 必要に応じて、UI スクリプトやリポジトリ プロシージャなどの他の依存環境の規則としてレンダリングできる抽象的な方法でクラス レベルで定義する必要があります。
これにより、クラス内の本来あるべき場所にロジックを一元化し、UI やその他の場所で補助的な検証を行うことができます。接続されていない場所に存在する切り離されたロジックではなく、クラスから派生しているため、簡単に保守できます。全勝。
私はすべての検証を、データがビジネス層で保持される場所にできるだけ近づけることで、多くの成功を収めてきました。たとえば、プロパティ セッターで。これにより、ビジネス層内で有効なデータのみを渡すことが保証され、UI がビジネス層から有効なデータを受け取ることも保証されます。
これにより、コードが常にビジネス層を通過する場合、データ層で多くの検証を行う必要がなくなります。
私が独断的である唯一のルールは、UI レベルの検証を決して信頼しないことです。このレイヤーは (特に Web アプリケーションでは) 最も簡単に侵害されるからです。UI レベルの検証は、ユーザー エクスペリエンスをより使いやすくするためのものです。
2 つの当事者間の契約 (インターフェース) は、A と B が特定の義務を負うように言います。契約書には何と書かれていますか？B は検証済みのデータを受け取ることになっていますか? その場合、B は検証を実装するべきではありません。しかし、A が UI の場合はどうでしょうか。明らかに、そこに検証を入れたくありません。通常、C などのサード パーティを導入するのが最善です。A は C と契約を結び、B と契約を結びます。B は検証済みのデータを期待します。Aはがらくたを送るかもしれません。C が検証を実行します。
契約が適切に設計されていれば、これが問題になることはほとんどありません。契約を取り直し、各当事者に義務を課します。特定の当事者があまりにも多くの義務を負っている場合は、第三者を紹介してください。
検証はオブジェクトの一部である必要があります。オブジェクトのコンストラクターのパラメーターの環境部分を作成します。そうすれば、環境の検証ロジックをカスタマイズできますが、オブジェクトは実行されている場所を把握する必要はありません。
せいぜい非常に弱いセキュリティですが、私は常に UI 検証を使用します。これにより、サーバーへのラウンド トリップが節約され (帯域幅は加算されます)、エラー メッセージをより使いやすくすることができます。しかし、それが検証の唯一のレイヤーであってはなりません。
確かに、Web 環境では、検証のためにクライアント側に置くものはすべてバイパスできます。
通常、私は検証をクラスに入れます。次に、セッターに例外を発生またはスローさせるか、必要に応じて戻り値を使用させます。私は .Net の世界で例外を使用します。これは、消費者/クライアントに返される明確な検証ルール メッセージを含む一連のカスタム例外を使用できるためです。