57

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

4

7 に答える 7

35

まず、この記事の執筆時点で 11,000 の質問が表示されているので、回答がないことに少し驚いています。また、かなり単純な質問であるにもかかわらず、回答の質に敬意を表します。

今日、Entity Framework Code-First が最近リリースされたことで、この問題がさらに当てはまると思われるため、少し話をしたので、この質問に答えたいと思います。

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

始める前にいくつかの明確化のポイント：

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

  • WCF に関するフォローアップの質問にお答えできるとは思いません。この理由は単純に、EF についてのあなたの質問に客観的に答えようとしているからです。そうすると、最初の質問に真正かつ客観的に答えようとする私の試みと矛盾することを証明するスタンスを主観的に取らざるを得なくなります。

とはいえ、ビジネス オブジェクトの質問として EF に...

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

申し訳ありませんが、ここには正解も不正解もありません。それは、目的が何であるか、およびその利点と欠点を十分に理解しながら、最も合理的な設計であると結論付けるものによって異なります。

「長所または短所を教えてください」</p>

質問してよかったです！喜んでお答えします。ビジネス オブジェクトに EF を使用することが「OK」であると信じるかどうかについて、長所と短所を考慮して、十分な情報に基づいた決定を下せることを願っています。通常、私は長所と短所を分けて「消化」しやすくしますが、これは適切ではないと思います。なぜなら、私たちは非常に興味深いトピックに不正をしていると思うからです。そして、私の心に愛しています。

まず、少し技術的な話をさせてください... EF オブジェクトをビジネス オブジェクトとして使用できます。技術的にそれを妨げるものは何もありません。実際のところ、EF Code-First (CF) を使用すると、POCO を作成できるようになり、単純な検証のためにデータ注釈を適用できるようになり、より複雑な検証のために IValidatableObject を実装できるようになるため、これが非常に簡単になります。かっこいいでしょ？

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

EF、または任意の ORM は、データ管理をサポートするように設計されています。その主な責任はデータであるため、作成するオブジェクトはデータ中心です。したがって、ビヘイビアによってオブジェクトを設計しようとしている場合は、ちょっとした難問を抱えていることになります。一言で言えば、この難問はインピーダンスミスマッチと呼ばれます。これを想像してください。アプリケーションには、次の 2 つのユース ケースが必要です。

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

EF (任意のフレーバー) または ORM を使用している場合、同じ「ユーザー」オブジェクトを使用して、ユーザーを保存する機能を処理したり、ユーザーを取得して読み取り専用フィールドのサブセットをプルしたりすることに引き寄せられる可能性があります。おそらく、いくつかの理由のいずれかでそうします。

  1. 多くの開発者と同様に、私たちは教育中にこの種を脳に植え付けています。「コードの統合」は最も重要であり、おそらく DRY – Don't Repeat Yourself として知られています。否定的な文脈。
  2. EF 4.1 などの ORM には、複数の POCO/オブジェクトを同じデータベース テーブルにマッピングするなどの技術的な制限 (およびハック的な回避策) があるため、信念に関係なく強制的に実行する必要があります。
  3. アプリケーションを起動して実行するための迅速かつ簡単な方法です
  4. 正しいことのように「感じる」

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

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

そして、コードに対する動作の正規化を信じるなら、惨めな失敗をしたことになると思います。コードを節約することで、オブジェクトの責任によってオブジェクトの設計が犠牲になり、管理が困難になり、その後維持コストが増加する可能性があります。

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

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

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

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

あなたがとる方向は、アプリケーションに依存する可能性が高く、哲学的な観点からは、あなたがどれだけ理想主義者または実用主義者であるかに依存する可能性があります. とは言っても、理想主義者または実用主義者であることが、ビジネス オブジェクトに EF を使用するかどうかと相関関係があると言っているわけではありません。単に、これに対する考え方に影響を与えるだけです。

これを書いている時点で、Microsoft によると、EF はビジネス ロジックを処理するように構築されており、正しいか間違っているかにかかわらず、EF はその方向に進んでいるように見えます。EF は常に進化しており、最終的に EF を使用して両方の世界の長所を満たすことができるように、特定の技術的制限が取り除かれています。言い換えれば、最終的にはケーキを手に入れて食べることもできるかもしれません.

お役に立てれば。

データを管理するという背後にある目的を考えると、ORM を使用した永続性を無視することはばかげているかどうかという質問に答えるためにオフにします。:-) すみません、我慢できませんでした！

于 2011-07-01T02:58:46.647 に答える
20

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

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

于 2008-10-20T12:48:01.720 に答える
13

エンティティ フレームワークは、エンティティ オブジェクトがビジネス オブジェクトとして使用されるように設計されていますが、ビジネス オブジェクトは EDM モデルだけでなく O/R テクノロジにも関連付けられることに注意してください。EF 1.0 では、持続性を無視するシナリオはサポートされていませんでしたが、4.0 でサポートが追加されました。基本クラスを使用したくない場合は、interfacesを実装できます。

.NET 3.5 SP1 の時点では、コードを追加しなくても、WCF サービス メソッドのパラメーターおよび戻り値の型としても使用できるはずです。

于 2008-10-20T06:38:24.930 に答える
4

私が遭遇したことに注意する2つの制限は次のとおりです。

  1. 継承されたオブジェクトはナビゲーションプロパティを持つことができません。つまり、「person」クラスがあり、次に「customer」と「supplier」がある場合、それらの顧客とサプライヤはナビゲーションプロパティを持つことができません。

  2. メソッドと計算フィールド（部分クラス内のすべて）はADO.Netデータサービスを介して送信されません-ADO.Netデータサービスも使用している場合、部分クラスでEntityFrameworkオブジェクトを展開したものはADO.Netを介して送信されませんデータサービス。

これらは通常、目立たないアイテムではありませんが（ナビゲーションプロパティの場合、現時点ではエンティティフレームワークで継承を使用していません）、興味があるかもしれません。将来のリリースでこれらの両方のアイテムが有効になることを期待しています。

于 2008-12-02T05:39:32.847 に答える
4

私の経験では、アプリケーションのビジネス レイヤー内で EF オブジェクトを使用しましたが、WCF サービス レイヤーを介してプレゼンテーション レイヤーに移行するときに、EF オブジェクトからビュー オブジェクトを作成します。

この場合、ビューのみがプレゼンテーション層に渡されます。これは、データの表示方法を制御し、プレゼンテーション層から入ってくるデータに防御的検証を適用するために行います。

WCF トランザクションで EF オブジェクトを使用する場合、EF オブジェクトが関連付けられていたオブジェクト コンテキストが失われます。これを支援しようとする CodePlex の取り組みがいくつかありますが、私は彼らの取り組みについていけていません。

于 2008-10-20T14:07:41.997 に答える
3

オブジェクトが元のオブジェクト コンテキストを失った場合、オブジェクトを再アタッチすることはできませんか? ただし、同時実行の問題を自分で処理する必要があります。

EF オブジェクトを WCF の DataContract オブジェクトとして使用することはお勧めしません。エンティティ オブジェクトの実装を Web サービス クライアントに非常に強く結び付けてしまうため、将来的に変更を行うのは難しくなり、計画しているクライアントが増えるほど難しくなります。

于 2008-11-11T07:33:19.340 に答える
2

WPF Application Framework (WAF)の BookLibrary サンプル アプリケーションは、Model-View-ViewModel (MVVM) パターンを Entity Framework と組み合わせて使用​​する方法を示しています。

于 2010-02-20T20:01:50.300 に答える