Entity Frameworkのエンティティをビジネスオブジェクトとして使用する

.net architecture entity-framework

質問

私はMicrosoftのEntity Framework O / Rマッパーを使用し、ビジネスオブジェクトとしてエンティティクラス(DBオブジェクトにマッピングされる生成クラス)を使用しています。これでいい?あなたの短所や長所を述べてください。ビジネスレイヤとプレゼンテーションの間のWCF通信の場合に何をするか、それらのオブジェクトをデータメンバとして送信する方法

受け入れられた回答

私はこの方法でEFを使用していますが、生成されたエンティティは部分クラスであるため、再生問題からかなり保護された方法で拡張することができます。

また、MSDN上のこのリンクで 、ビジネスロジックに関するEFの一般的な使用シナリオについて説明してください


人気のある回答

この記事の執筆時点での11kの質問ビューで、まず第一に、私は、答えがないこと、そして十分に尊重された答えの質、かなり簡単な質問を考えると少し驚いています。

それで、もう少し換気したので、この質問に対処したいと思います。それは、最近のEntity Framework Code-Firstのリリースでさらに当てはまると思うからです。

「ビジネスオブジェクトとしてEntity Frameworkエンティティを使用しますか?」

始める前に、いくつか明確にしておきます。

  • 「ビジネスオブジェクト」と言うとき、私が参照するこれらのオブジェクトには、単純な検証(つまり必須フィールド)からより複雑なロジック(つまり、チェックアウト時の処理税)まで、さまざまなルールやロジックが含まれるという印象を受けます。

  • WCFに関するフォローアップの質問に回答できるとは思いません。その理由は、ビジネスオブジェクトとしてのEFについてのあなたの質問に客観的に答えるつもりであり、それが私の最初の質問に真に客観的に答える試みと矛盾する立場を取るように主観的に強いるからです。

ビジネスオブジェクトの質問としてあなたのEFにそれは言った...

「MicrosoftのEntity Framework O / Rマッパーを使用しており、ビジネスオブジェクトとしてエンティティクラス(DBオブジェクトにマップされる生成クラス)を使用しています。これで問題ありませんか?」

申し訳ありませんが、ここに正解または不正解はありません。それはあなたの目的が何であり、あなたがそうすることの長所と短所を十分に理解しながら最も合理的な設計であるとあなたが結論するものに依存します。

「短所や長所を教えてください」

よろしくお願いします。喜んでお答えします。ここで私は、長所と短所を考えて、ビジネスオブジェクトにEFを使用することが正しいかどうかについて十分な情報に基づいて決定を下すことができます。通常、私は長所と短所を切り分けて「要約」するのを簡単にしていますが、ここではそれが適切であるとは考えていません。これは私の心にも近いし愛することでもあります。

最初に、技術的にちょっと話をさせてください。EFオブジェクトをビジネスオブジェクトとして使用することはできますが、技術的に不可能にすることはできません。実際のところ、EF Code-First(CF)を使用すると、POCOを作成して簡単な検証にデータ注釈を適用したり、より複雑な検証にIValidatableObjectを実装したりできます。かなりかっこいいね。

そこに議論の中心があります。

EF、または任意のORMは、データ管理をサポートするように設計されています。その主な責任はデータであり、したがってあなたが作成するオブジェクトはデータ中心です。だから、もしあなたがあなたのオブジェクトを振る舞いによってもデザインしようとしているなら、あなたは手元に少しの難問を持っています。簡単に言えば、この問題はインピーダンス不整合と呼ばれます。これを描きます。アプリケーションには2つの必須ユースケースがあります。

  1. ユーザーを編集するための画面
  2. ユーザー情報の読み取り専用サブセットを表示するためのコントロール

EF(任意のフレーバー)またはそのことについて任意のORMを使用している場合は、同じ「User」オブジェクトを使用してユーザーを保存したり、読み取り専用フィールドのサブセットを取得したりすることができます。 。あなたはおそらくいくつかの理由のうちの1つのためにそうするでしょう:

  1. 多くの開発者と同様に、私たちは教育の最中にこの種を頭の中に植えています。「コードの統合」は最も重要であるか、またはおそらく「DRY」として繰り返すことをお勧めします。否定的な文脈では、プロパティとして。
  2. EF 4.1などのORMには、複数のPOCO /オブジェクトを同じデータベーステーブルにマッピングするなど、技術的な制限(およびハッキングな回避策)があり、それによって自分の信念に関係なく強制されます。
  3. アプリケーションを立ち上げて実行するための迅速で簡単な方法です。
  4. それは「気分」が正しいことです。

そうすることの長所と短所があり、あなたはこれを見ることができるあなたの意見に応じて肯定的または否定的な方法です。

私はあなたがあなたが大いに成功したよりも、振る舞いよりもコードの正規化を信じるかと思います。そのエンティティのデータとビジネスのユースケースを処理する単一のオブジェクトを作成することで、コード量を制限し、時間を節約することができました。

そして、あなたが惨めに失敗したよりも、あなたがコード上の振る舞いの正規化を信じるならば、私は思います。コードを節約することで、オブジェクトの責任によってオブジェクトを設計することが犠牲になり、管理が難しくなり、その後の維持管理コストが増大します。

あなたの意見に関係なく、このビジネスオブジェクトは複数の責任を負っており、そのオブジェクトの振る舞い(データではない!)はせいぜい二次的なものであると私たちは皆同意することができます。その主な責務はデータの管理であり、その副次的な責務は、ユーザーの編集および読み取り専用のユーザー情報の表示に関連する、単純で複雑なビジネスルールの処理です。オブジェクト指向設計(OOD)では、オブジェクトのアイデンティティと動作によってオブジェクトの設計が特徴付けられる場合、このオブジェクトはOODの定義に従わないため、混乱した1人の個人になる可能性があります。

技術的な観点から考えると、ユーザーオブジェクトを要求するたびに、かなりの量のオーバーヘッドが継承されます。これには、読み取り専用情報のサブセットのみを表示するときのすべてのプロパティやビジネスルールなどが含まれます。

それでは、ビジネスオブジェクトを表すためにEFを使用する必要があるかどうかに関係なく、これらすべてがどう関係するのでしょうか。

それは技術的には可能ですが、ビジネスオブジェクトを表すためにEFまたはORMのどちらを使用すべきかどうかについては、異なる考え方(いくつか良い、悪いなど)があります。私は上記のこれらの哲学の中心を目的とした概要を述べましたが、それらはRocky LhotkaやMartin Fowlerのような個人によってもっと詳細に文書化されています。

あなたが取る方向は、おそらくアプリケーションや哲学的見地から、あなたがどれだけ理想主義者または実用主義者であるかに依存するでしょう。とは言っても、理想主義者でも実用主義者でもある人がビジネスオブジェクトにEFを使用することに関連するのか、それとも単にこれに影響を与えるのではないのかという意味ではありません。

これを書いている時点で、マイクロソフトによる指摘は、EFはビジネスロジックを処理するように構築されているということであり、そして正しいか間違っているか、それらはその方向にもっと動いているように見えます。 EFは絶えず進化しており、EFが最終的に両方の長所を満たすために使用される可能性があるため、特定の技術的制限が取り除かれています。言い換えれば、結局あなたはあなたのケーキを持ってそれをも食べることができるかもしれません。

お役に立てれば。

データを管理することが目的であることを考えると、ORMでの永続性の無知が疑問であるかどうかについての質問に答えることはできません。 :-)すみません、私は抵抗できませんでした!



Related

ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow