0

検証を実装するのに最適な場所はデータベースにできるだけ近いように思われるため、エンティティ フレームワークを使用する場合、最も近いオブジェクトはエンティティであり、私の場合は POCO エンティティです。

その理由は、この POCO エンティティを再利用したい場合、検証が POCO オブジェクトに実装されているため、摩耗したデータをデータベースに挿入する可能性が少なくなるためです。

これにより、誰かがデータベースに誤ったデータを挿入して別のアプリケーションを作成しようとしたり、検証を実装していないために回避したりすることもできます。そのため、より安全です。

これを行う 1 つの方法は、POCO エンティティを拡張し、IValidatableObject インターフェイスを実装して validationresult のリストを返す部分クラスを使用することです。

しかし、他の方法は次のとおりです。次のような一般的なアセンブリがあります。

  • リポジトリの実装に必要なメソッドを宣言する 1 つのインターフェイス。
  • リポジトリで使用される POCO エンティティ。
  • エンティティのコピーやエンティティのデータを検証するメソッドなどのユーティリティを備えた 1 つのクラス。

次に、さまざまなバージョンの EF または別のテクノロジを使用する多くのリポジトリを作成できますが、それらはすべて共通のアセンブリを使用します。このリポジトリは、共通ライブラリのメソッドを使用して検証を実装します。

この場合、検証を 1 回だけ実装します。唯一の問題は、リポジトリがメソッドを呼び出してデータを検証する必要があることです。

しかし、私の観点からは、このように利点があります。たとえば、操作の種類に応じてエンティティのデータを検証できます。たとえば、新しいレコードと主キーを自動数値として追加している場合、ID が 0 でない場合は例外をスローできます。ID が 0 のときにレジスタを削除しようとすると、例外をスローできません。コマンドをデータベースに送信する必要はありません。

したがって、この2番目のソリューションは、データベースにできるだけ近い検証を実装するという問題を解決します。これは、データベースにアクセスする要素であるリポジトリで使用されるためですが、開発者が新しいリポジトリを作成し、作成しない場合に問題があります。検証方法を使用すると、データベースに誤ったデータが含まれる可能性があります。

したがって、私の質問は、部分クラスで検証を使用するか、共通ライブラリを使用して検証をリポジトリに実装することが最善の選択肢であるかどうかです。それは実際にユーザーが使用するものです。

ありがとう。

4

1 に答える 1

1

OK - ふー、大きな質問です。私の意見では、アプリケーションの APPLICATION DOMAIN がすべての主役です。データベースは単なるアドオン サービスです。したがって、アプリケーション ドメインは最終的に、どこかに送信されているすべてのオブジェクトを検証する必要があります。DB から出てくるオブジェクトは入ってくることが検証されているため、検証する必要はありません。

例として、Web サービスに送信する必要があり、検証が必要なオブジェクトを作成していたとします。データベースやリポジトリに近づくことはなかったとしましょう。DOMAIN ビジネス オブジェクトが検証されると、永続化のために、または他の場所に送信できます。

考慮すべきもう1つのことは、検証の意味です。データ型が正しいということですか?ビジネスオブジェクトが有効であることを意味しますか? ビジネスオブジェクトが特定のコンテキストで有効であることを意味しますか? これらのすべてまたは一部のみを意味する場合があります。

例として、システムでユーザーがレコードを部分的に更新できるようにするとどうなるでしょうか (入力フォームが非常に長い場合によくあることです)。ビジネス オブジェクトは、必要なすべてのデータが取得された場合にのみ有効になりますが、データベースでは「部分的な」データの永続性が許可されます。言い換えると、ビジネス オブジェクトはまだ有効ではありませんが、データベースに保存することができます。などなど……

于 2013-09-04T18:26:04.590 に答える