Entity Framework 6.0でのORMエンティティとドメインエンティティ
私は次の2つの記事を偶然見つけました First と Second では、著者は要約してORMエンティティとドメインエンティティを混同すべきではないと述べています。
Code Firstアプローチを使用してEF 6.0でコーディングする際、現時点ではまさにこの問題に直面しています。 POCOクラスをEFのエンティティおよびドメイン/ビジネスオブジェクトとして使用します。しかし、EFフレームワークによって強制されているため、プロパティをパブリックまたはナビゲーションプロパティを仮想としてのみ定義している状況に頻繁に気づきます。
2つの記事の一番下の行として何をすべきかわかりませんか？たとえば、エンティティフレームワークのCustomerEFクラスとドメインのCustomerDを実際に作成する必要があります。次に、CustomerDを消費するリポジトリを作成し、CustomerEFにそれをマッピングします。いくつかのクエリを実行し、受信したCustomerEFをCustomerDにマッピングします。 EFとは、ドメインエンティティをデータにマッピングすることです。
アドバイスをお願いします。 EFが私に提供することができる重要なことを見落としていますか？または、これはEFによって完全に解決できない問題ですか？後者の場合、この問題を管理する良い方法は何ですか？
これらの投稿の一般的な考え方に同意します。 ORMクラスモデルは、何よりもまずデータアクセス層の一部です（いわゆるPOCOで構成されている場合でも）。永続性とビジネスロジック（またはその他の懸念事項）の間に利益相反が生じた場合、永続性を優先して決定を行う必要があります。
しかし、ソフトウェア開発者として、私たちは常に純粋主義と実用主義のバランスを取る必要があります。永続性モデルをドメインモデルとして使用するかどうかは、いくつかの要因に依存します。
開発チームの規模/一貫性。 ORMの要件だけでプロパティがパブリックになり得るが、あちこちに設定するべきではないことをチーム全体が知っている場合、大したことではないかもしれません。 IDプロパティがビジネスロジックで使用されないことを誰もが知っている（そして従う）場合、IDを持つことは大したことではないかもしれません。散在する、経験のない、または規律のないチームには、より厳格なコードの分離が必要になる場合があります。
ビジネスロジックの懸念と永続性の懸念の重複。クラスモデルが [〜＃〜] solid [〜＃〜] 原則に固執すると、オブジェクト指向設計が成功します。しかし、これらの原則は、永続性の懸念と必ずしも対立するものではありません。懸念は異なりますが、最終的には、結果として生じる要件は非常に似ている可能性があります。たとえば、両方の懸念事項には、有効なオブジェクトの状態と正しい関連付けが必要になる場合があります。
ただし、オブジェクトを一時的に絶対に保存しない状態にする必要があるユースケースもあります。これは、専用ドメインクラスを使用する理由かもしれません。もう1つの理由は、エンティティモデルが責任の最適なセグメンテーションを実行できないことです。たとえば、ビジネスプロセスの「顧客をブラックリストに載せる」には、非常に多くのエンティティオブジェクトに散らばるデータが必要な場合があります。そのため、データとそれらに作用するメソッドをカプセル化できる新しいドメインクラスを設計する必要があります。言い換えれば、エンティティによってこれを行うと、 Tell Do n't Ask 原則に違反することになります。
階層化の必要性。たとえば、データアクセスレイヤーが異なるデータベースベンダーを対象とする場合、ベンダー固有の交換可能なパーツで構成する必要がある場合があります（たとえば、OracleとSql Server間のデータタイプの微妙な違いを考慮したり、ベンダー固有の機能を活用したりするため）。永続性モデルをドメインモデルとして使用すると、おそらくベンダー固有の実装がビジネスロジックに流れ込んでしまいます。それは本当に悪いでしょう。そこでは、データアクセスレイヤーはまさにレイヤーでなければなりません。
（非常に簡単）データの量。オブジェクトの作成には時間とリソースがかかります。ビジネスケースに「多くの」オブジェクトが関与している場合、エンティティオブジェクトとドメインオブジェクトの両方を構築するにはコストが高すぎる場合があります。
そして、間違いなく。
だから私はいつもプラグマティストになろうとしています。エンティティクラスが適切な仕事をする場合は、それを実行します。不一致が大きすぎる場合は、ビジネスロジックの適切な部分のビジネスドメインを作成します。それが良いパターンだからといって、私は（どんな）デザインパターンにも従わないでしょう。投稿で述べられていることとは反対に、エンティティモデルをビジネスモデルにマッピングするには多くのメンテナンスが必要です。エンティティクラスとほぼ同一の無数のビジネスクラスを作成していることに気付いたら、今何をしているのかを考え直すべき時です。