在多个项目中使用EntityFramework

Question

我正在努力解决如何在多个Visual Studio项目中打破域模型的最佳方法。我正在使用EntityFramework 4和企业类型模式来合理化一个可以重用于各种应用程序的系统。最终，我想得到一组混合和匹配的DLL类库，可以在Web应用程序中重用。

Sor far，我有一个标准的数据库架构，其中包含用户信息，基本CRM，基本CMS以及轻量级电子商务平台。

CRM /用户表是系统的核心。 CMS和电子商务平台使用CRM用户表。我想定义一个核心域模型，CMS和电子商务领域模型从中链接/派生。

到目前为止，我有三个视觉工作室项目：

• MyNamespace.Model.Core
• MyNamespace.Model.CMS
• MyNamespace.Model.Commerce

在每个模型中都有一个Entity Framework Domain Model EDMX文件。 EDMX包含每个的所有相关表。这意味着CMS和Commerce项目的EDMX文件包含一些用户表。理论上我可以有一个大的EF模型并将所有POCO放在一个类中，但这不是很容易扩展。

项目还包含每个表的POCO（这些可能在一个单独的项目中，但在事情分类之前，它们可以保持原样！）。

当我在具有工作单元的服务层中使用域模型时，我只想使用一个ObjectContext（这实际上是一个以EF ObjectContext为目标的IObjectContext包装器）。出于这个原因，我为每个EDMX文件提供了相同的实体容器名称和命名空间。

问题：

1. 这是正确的做法吗？
2. 如果同一名称空间中的EF模型具有相同的容器名称（虽然跨越不同的项目），如果在这些不同的模型中重复使用表/实体（例如客户），这会导致问题吗？

Answer 1

公平点，一些评论：

1. 据我所见，这是最大的问题。我想可以通过使用（例如）适当的CRM.Person和适当的Commerce.Person来实现。我认为我想要实现的是一个普通的POCO模型，EF域模型位于其下方。我不太关心EF模型是如何构建的，除了它应该是合理的结构。

2. 再次，下一个最大的问题。通过在不同的上下文中具有重复实体来解决某种程度，但这意味着某些导航属性不可用。例如，CRM.Person不会拥有Commerce.Person所拥有的订单，运输等属性，即使他们是数据库中的“相同”人员。

3. 基于反射的逻辑（目前）对我来说并不重要。

4. 同意。因此，为什么我想以某种方式走向一个上下文

5. 工作单元实际上是一个IUnitOfWork，并且被存入存储库并且需要独立于EF。

6. 不同意。我们的想法是建立一个核心应用程序，必要时可以扩展。例如，未来的项目可能涉及剧院预订。这将与Commerce核心绑定，但我不想重新编程Commerce应用程序来解释它。就我而言，重建EDMX模型并不理想。可能是唯一的方法。

   1. 我可以看到这怎么可能发生！
乍一看似乎这是EF的一个缺点，尽管可能有一个很好的理由不做我想做的事情。也许Microsoft应该包含某种方法，其中两个具有相同容器名称的EDMX域模型在运行时合并。有效地（并且想要更好的词）EDMX模型会变得“偏”，只要没有任何冲突，我就不会发现太多错误了吗？

Answer 2

EF很新，几乎每个人都喜欢你在试验并找到创造更好系统的新方法。所以不会有任何直接的答案，但我可以把我的想法和我已经遇到的问题放在一边。

多个EDMX的问题

1. 分享实体以构建更通用的逻辑将很困难，因为您最终会在多个上下文中具有相同的命名实体。
2. 如果要将它们存储在一个数据库中，那么将来您可能需要处于不同上下文的两个实体之间的连接和关系。
3. 编写基于反射的通用逻辑是不可能的。
4. 跨多个上下文的工作单元将很复杂。
5. EF已经实施了工作单元，RIA服务将是一个很好的候选人，而不是重新实现整个事情。
6. 将所有内容保存在一个上下文中将允许您构建可扩展的应用程序。并且大多数代码都将自动生成，因此它不会产生太大的影响。
7. 我们确实尝试了这个，我们意识到后来它需要大量的胶水代码，随着代码和报告的重复变得很麻烦，事情变得很脏，我们终于在一个环境中移动了所有内容。

如果我要将所有内容存储在一个数据库中，我将其视为一个存储库。