0

EF4.0 から EF5.0 および Code First への最近のアップグレードで、Domain Model を Code First と連携させるためのいくつかのルールについて、私たちのチームは、1 対 1 のマッピングを表す永続オブジェクトの POCO を作成することで、懸念事項を分割することにしました。これらの永続的な POCO 内のデータベース列と関係。永続オブジェクトごとに FluentApi 構成を使用して、暫定的にこれらを「永続オブジェクト」と呼びました。一部のドメイン オブジェクトは、抽象クラス、いくつかのインターフェイス、およびビジネス ルールからの仕様を利用して、これらの永続オブジェクトのいくつかに分割されます。DDD はドメイン ビジネス オブジェクトを「エンティティ」と呼ぶため、EF はエンティティを指すため、これは紛らわしいことがわかりました。POCO を別のライブラリ プロジェクトに配置しました。私には、それらは DAO のように見え始めました。

上記を考えると、Domain Object を Code First の永続化可能な POCO コントラクトから分離するという選択肢はありますか?

私が提起した反論は、これは永続オブジェクトが WCF Data Service オブジェクトとして公開されることを意味するということです。小さな作業バージョンができるまで開発を停止しました (コア オブジェクトを 5 つのテーブルと 3 つのドメイン オブジェクトにプッシュできます)。私は、これがベスト プラクティスであるか、青本のエリックの概要に似た別の方法であると確信できるまで、他の 70 以上の POCO を進めたくありませんでした。

4

1 に答える 1

2

私はそれを行い、ドメイン エンティティと EF マッピング クラスを別々のプロジェクトに分割しました。私はnhibernateでもそれをしました。インフラストラクチャ関連のプロジェクトにマッピング クラスを保持します。あなたの持続性に関する知識です。

wcf サービスのエンティティの公開に関しては、アプリケーション レイヤーを使用して、Data Transfer Object パターンでデータを公開することをお勧めします。派手なものはありません。wcf APIの粒度をより適切に制御できるようにするだけです。通常、ドメイン エンティティは非常に低いレベルにあるため、特定のインタラクション (ユース ケース) に必要なデータを取得するには、知識と複数の呼び出しが必要です。

于 2013-07-03T06:44:46.260 に答える