.net - 跨多个项目使用 EntityFramework

Question

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

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

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

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

MyNamespace.Model.Core

MyNamespace.Model.CMS

MyNamespace.Model.Commerce

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

这些项目还包含每个表的 POCO(这些可能应该在一个单独的项目中，但在事情整理好之前，它们可以保持原样!)。

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

问题:

这是正确的做法吗？

如果在同一个命名空间中有具有相同容器名称的 EF 模型(尽管跨不同的项目)，如果在这些不同的模型中重复表/实体(例如客户)，这会导致问题吗？

Answer 1

公平的观点，一些评论:

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

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

基于反射的逻辑(目前)对我来说并不重要。

同意。因此，为什么我想以某种方式接近一个上下文

工作单元实际上是一个 IUnitOfWork 并且被 DI 到存储库中并且需要独立于 EF。

不同意。我们的想法是开发一个可以在必要时扩展的核心应用程序。例如， future 的项目可能涉及预订剧院。这将与 Commerce 核心相关联，但我不想重新编程 Commerce 应用程序来解决它。就我而言，重建 EDMX 模型并不理想。不过可能是唯一的办法。

我可以看到这怎么可能发生!

乍一看，这似乎是 EF 的一个缺点，尽管不做我想做的事情可能有很好的理由。也许微软应该包括某种方法，在运行时合并两个具有相同容器名称的 EDMX 域模型。有效地(并且想要一个更好的词)EDMX 模型将变得“部分”，只要没有任何冲突，我就看不出有太多错误？