4

私は、EF 4 が POCO で何ができるかを確認するプロジェクトを開始しました。データベースとカスタム POCO を作成しました。今、私は自分のデータを検証したいと考えています。このために、私は Enterprise Library Validation Block 5 を使用しています。

属性を介してPOCOに検証を含め、Entity Frameworkで使用しても問題はありませんが、検証フレームワークへの依存関係を挿入したため、POCOがPOCOではなくなることを意味します。

どこに検証部分を挿入し、POCO をきれいに保つべきかアドバイスはありますか?

4

3 に答える 3

2

個人的には、エンティティの一部として検証を行うことにそれほど問題があるとは思いません。結局のところ、エンティティはドメイン モデルの一部であり、検証ルールはおそらくそれらの属性の一部と考えることができます。私はドメインモデリングの専門家ではありません:)

最終的に、検証はエンティティとある程度結合する必要があります。カップリングを減らすことにした場合、ぎこちないコードで終わるリスクがあると思います。私の最新のプロジェクトでは、検証をさまざまなクラスに分割し、エンティティの部分クラスに配置しました。これまでの結果には非常に満足しています。

于 2010-09-06T07:29:41.937 に答える
0

サービス クラスを作成し、そのクラスで検証を行います。

たとえば、Listing という POCO クラスがあるとします。ListingService というサービス クラスを作成します。次に、ValidateListing というメソッドで ListingService の検証を行います。

于 2010-11-14T15:26:40.410 に答える
0

I agree that you would like to keep your entities free from validation. It is not the responsibility (SRP) of the domain object itself.

Besides attribute based validation, the Enterprise Library Validation Application Block (VAB) also supports configuration based validation. There are two models you can follow here:

  1. Use XML based configuration. This is well supported. The VAB contains a configuration tool that allows you to configure the whole thing without writing a single line of XML. Especially the 5.0 tool is very good. Still, using XML makes it hard to refactor anything in your model (however, unit tests will help you spot error sooner).

  2. コードベースの構成の使用。個人的にはこのモデルが好きですが、ドメインのリファクタリングを容易にする上ではるかに優れた仕事をすることができるからです。動作させることはできますが、まだ十分にサポートされていません。このスレッドを見て、ベースの構成をコーディングする方法の例と、現在の欠点を確認できます。

幸運を。

于 2010-09-06T09:14:36.633 に答える