70

次の 2 つの記事 (1 番目と 2 番目) に出くわしました。この記事の著者は、ORM エンティティとドメイン エンティティを混同すべきではないと要約しています。

Code First アプローチを使用して EF 6.0 でコードを作成しているとき、私はまさにこの問題に直面しています。POCO クラスを EF のエンティティとして、またドメイン/ビジネス オブジェクトとして使用します。しかし、プロパティを public として定義したり、ナビゲーション プロパティを virtual として定義したりする状況に陥ることはよくあります。これは、EF フレームワークで強制的にそうする必要があるためです。

2 つの記事の結論として何を理解すればよいかわかりません。たとえば、エンティティ フレームワーク用の CustomerEF クラスとドメイン用の CustomerD を実際に作成する必要があります。次に、CustomerD を使用するリポジトリを作成し、それを CustomerEF にマップし、いくつかのクエリを実行してから、受信した CustomerEF を CustomerD にマップします。EF とは、ドメイン エンティティをデータにマッピングすることだと思っていました。

ですから、アドバイスをお願いします。EF が私に提供できる重要なことを見落としていませんか? それとも、これは EF では完全に解決できない問題ですか? 後者の場合、この問題を管理する良い方法は何ですか?

4

1 に答える 1

85

これらの投稿の一般的な考え方に同意します。ORM クラス モデルは、何よりもまずデータ アクセス層の一部です (いわゆる POCO で構成されている場合でも)。永続性とビジネス ロジック (またはその他の懸念事項) の間で利益相反が発生した場合は、常に永続性を優先する決定を下す必要があります。

ただし、ソフトウェア開発者として、私たちは常に純粋主義と実用主義の間でバランスを取る必要があります。持続性モデルをドメイン モデルとして使用するかどうかは、いくつかの要因によって異なります。

  • 開発チームの規模/一貫性。チーム全体が、ORM 要件のためだけにプロパティをパブリックにできるが、あちこちに設定すべきではないことを知っている場合、それは大したことではないかもしれません。ID プロパティがビジネス ロジックで使用されるべきではないことを誰もが知っている (そして従う) 場合、ID を持つことは大したことではないかもしれません。分散した、経験の浅い、または規律のないチームは、より厳密なコードの分離が必要になる場合があります。

  • ビジネス ロジックの懸念と永続化の懸念の重複。オブジェクト指向設計は、クラス モデルがSOLIDの原則に固執するときに成功します。しかし、これらの原則は、持続性の懸念と必ずしも相反するものではありません。つまり、懸念事項は異なりますが、最終的に結果として得られる要件は非常に似ている可能性があります。たとえば、どちらの懸念にも、有効なオブジェクトの状態と正しい関連付けが必要な場合があります。

    ただし、絶対に保管してはならない状態にオブジェクトを一時的に置く必要がある場合もあります。これが、専用のドメイン クラスを使用する理由になる場合があります。もう 1 つの理由は、エンティティ モデルが責任を最適に分割できないことです。たとえば、「顧客をブラックリストに載せる」というビジネス プロセスでは、非常に多くのエンティティ オブジェクトに散在するデータが必要になる場合があるため、データとそれらに作用するメソッドをカプセル化できる新しいドメイン クラスを設計する必要があります。言い換えれば、エンティティでこれを行うと、Tell Don't Askの原則に違反します。

  • レイヤリングの必要性。たとえば、データ アクセス レイヤーがさまざまなデータベース ベンダーを対象とする場合、ベンダー固有の交換可能な部分で構成する必要がある場合があります (たとえば、Oracle と Sql Server の間のデータ型の微妙な違いを説明したり、ベンダー固有の機能を活用したりするため)。持続性モデルをドメイン モデルとして使用すると、ベンダー固有の実装がビジネス ロジックに流れ込む可能性があります。それは本当に悪いでしょう。そこでは、データアクセスレイヤーはまさにそれ、レイヤーである必要があります。

  • (非常に些細な) データの量。オブジェクトの作成には時間とリソースが必要です。ビジネス ケースに「多くの」オブジェクトが含まれる場合、エンティティ オブジェクトとドメイン オブジェクトの両方を構築するにはコストがかかりすぎる可能性があります。

さらに、間違いなく。

だから私は常にプラグマティストになろうとします。エンティティークラスがまともな仕事をするなら、それを選びましょう。不一致が大きすぎる場合は、ビジネス ロジックの適切な部分に対してビジネス ドメインを作成します。それが良いパターンだからという理由だけで、(どんな) デザインパターンにも従うことはありません。投稿で述べられていることとは反対に、エンティティ モデルをビジネス モデルにマッピングするには多くのメンテナンスが必要です。エンティティー・クラスとほとんど同じである無数のビジネス・クラスを作成していることに気付いたときは、自分が何をしているかを再考するときです。

于 2013-08-07T20:52:40.280 に答える