EntityFramework：スライスするかスライスしないか？

Question

私はEntity Frameworkを使い始めました。私は非常に大きな既存のデータベースを使って作業しています。私はデータベース全体の「スライス」であるモデルを作成するためにEFを使いたいと思っています。これらのスライスはアプリケーションの1つの側面に対応しています。それはそれを見る正しい方法ですか、1 EDMXでデータベース全体をモデル化するべきですか？

は、私はあなたに架空の例を挙げてみましょう：

は、このデータベースに含まれている多くのものの1は、顧客の課金情報であると仮定します。私は、Customer Billingモジュールが対話する必要のあるテーブルに焦点を絞ったEFモデルを作成したいと思っています。 （したがって、そのモデルはアプリ内の他のモジュールには使用されず、他の小さなEFモデルにも同じテーブルが表示される可能性があります）。これにより、EFの概念モデル機能（継承など）を活用して、カスタマサポート（2つのモジュールがいくつかのテーブルを共有しているにもかかわらず）で、そのモデルの影響を気にせずに顧客請求に適したビューを構築できます。

それは正しいと思いますか？

Answer 1

私にはちょっと聞こえます。結局、エンティティモデルのポイントは、a level of abstraction that's appropriateにある永続化可能なビジネスオブジェクトのセットを必要なビジネスロジックに提供することです。

基本的なデータベーススキーマをコピーするモデルではなく、アプリケーションのモジュールをサポートするエンティティモデルを絶対に作成する必要があります。上記のリンクが示すように、永続性から論理を分離することは、EFの主な目的の1つです。

Answer 2

私はその理由を次のベース、スライスアプローチを使用することを好むだろう：

• あなたがテーブルの負荷を持つ大規模なデータベースを持っている場合、大規模なエンティティモデルを管理するのは困難であろう。
• エンティティ・フレームワークはエンティティ・マッピングには対応していないため、アプリケーション/ドメイン固有のエンティティを管理する方が簡単です。カスタム・エンティティを作成し、エンティティ間で表を結合および分割することもできます。