2

重複の可能性:
ビジネス オブジェクトとして Entity Framework エンティティを使用していますか?

Entity Framework を ORM として使用することを検討していますが、たくさん読んだ後、EF オブジェクトが正確にどこに適合するかについて本当に混乱しています。

私は、ORM の要点は、オブジェクトをリレーショナル データベースにマッピングすることの煩わしさと複雑さを取り除くことであるという印象を受けました。DB をロードして、魔法のようにたくさんのオブジェクトを取得します。CRUD はすべてオブジェクトに対して行われます。DB が変更された場合、マッピングを変更しますが、オブジェクトは同じままです。

これは、システム全体でこれらのオブジェクトを使用すること、およびそれらが動作することを意味します。それらはビジネス オブジェクトです。これは私には理にかなっており、実際にMSは動作を追加する方法を教えてくれます

ただし、データの永続性のみに関心があり、ビジネス オブジェクトを EF と結合するため、EF オブジェクトをビジネス オブジェクトとして使用するべきではないと多くの人が言っているのを読んでいます。彼らは、データ層の抽象化として EF を使用し、それらを実際のビジネス オブジェクトにマッピングすることを提案しています。

これは私には無意味に思えます。ビジネス オブジェクトにマッピングすることになるのに、なぜ別の抽象化レイヤーが必要なのですか? EF プロパティをマップする必要がある場合は、DB 列をマップすることもできます。

ORM の要点は、マッピングを自動化し、バッキング ストアの抽象化として機能することだと思いましたか? 何か不足していますか？

編集:動作とは、ビジネス ロジックを意味します。検証、計算されたプロパティ、ビジネス メソッドなど。

4

2 に答える 2

2

一般に、EF で生成されたクラスをビジネス層として使用すべきではないと言う人々は正しいです。

ただし、小規模なアプリケーションでは、UI から直接 EF クラスを使用することで問題を解決できます。

アプリケーションのサイズと機能が大きくなるにつれて、UI から EF クラスを使用する際に問題が発生することは間違いありません。N+1 (ビューで発生する遅延読み込み)、シリアル化 (循環参照)、AJAX/jQuery (大きすぎるオブジェクトの送信) を選択します。小規模な更新シナリオ用のワイヤ経由のグラフ) など。

多くの場合、AutoMapper (https://github.com/AutoMapper/AutoMapper) を使用して EF クラスと DTO クラスおよびビジネス レイヤー クラスをマッピングし、多くのマッピング コードを記述する退屈な作業を軽減することをお勧めします。

これは間違いなくプロジェクトの要件に基づいて下すことができる決定であり、必ずしも正しい答えがあるとは限りません。痛みを感じ始めたら、いつでも方向を変えることができます。いつものように、プロジェクトで実行可能な最も単純なソリューションを選択してください。

于 2012-08-07T11:36:18.613 に答える
1

DB が変更された場合、マッピングを変更しますが、オブジェクトは同じままです。

いいえ。データベースを変更すると、マップされたエンティティ クラスも変更されます。ただし、これらのクラスをビジネス ロジックに使用できないというわけではありません。そのまま EF を使用すると、エンティティ クラスがクラスとして作成されるpartialため、生成されたコードによって上書きされないように独自のコードを追加することができます。

（...）[EFオブジェクト]はデータの永続化のみに関係していると言っている人々

私はそうは思わない。それらはデータ ストアに永続化され、データ ストアから入力されるように設定されている場合がありますが (データベース ファーストで作業する場合と同様)、それは問題ではありません。この追加された動作を無視し、ビジネス ロジックで使用しないでください(私の意見です)。オブジェクトは永続性を無視しているのではなく、ビジネス ロジックはそうあるべきです。

そうは言っても、私は常にビジネス ロジックにエンティティ クラスを使用しています。しかし、細心の注意を払って責任を分離したオブジェクトを緊密に連携させるという意味で、私はもはや純粋な OO のファンではありません。理由は 2 つあります。

  1. ほとんどのアプリケーションには、ある種のビジネス レイヤーとビュー モデルを含むビュー レイヤーが含まれており、コントローラー レイヤーによって結合され、シリアル化が必要な境界を越えて通信します。そのため、ドメイン クラスの動作を直接呼び出すことは、多くの場合オプションではありません。したがって、私は DTO を介して通信するサービス クラスまたはファサードでより多くの BL をプログラミングする傾向があり、他のレイヤーから直接アドレス指定されるドメイン モデルではより少なくプログラミングする傾向があります。これらのサービス メソッドは、ビジネス ロジックに最適な場所である傾向があります。そのため、ほとんどの場合、クラス自体にデータが含まれ、他の EF クラスとの連携を必要としないロジックで EF クラスを拡張します。これにより、遅延読み込みの例外や n+1 の問題も回避できます。サービスメソッドでドメインロジックからBLに喜んで移行した多くの例を示すことができましたが、それは'

    OnPropertyChanging/Changed同様に、MS リンクの 1 つが説明しているように、私は使用するのが好きではありません。私はそれをやった、それはスパゲッティです。ビューモデルでは、たとえばユーザー入力に応答するのに役立ちますが、ドメインクラスでは、プロパティを設定することは、プロパティを設定する必要があります。忘れられて、いつかあなたを噛む追加の行動はありません。

  2. Linq やその他の .Net 言語構造によって奨励された (ステートレス) 関数型プログラミング パラダイムの進歩。

そのため、実際にはそこに到達することはありませんが、ドメイン モデルが貧血ドメイン モデルに近づいていることがわかります。私は、これが今日では完全に理にかなっている理由をいくつか挙げようとしました。

于 2012-08-06T14:45:02.647 に答える