设计决策：多个EF EDMX文件

Question

如果您使用了实体框架，那么您知道EDMX很酷。你也知道它会变得巨大而且几乎难以控制。

当它变大时，很容易为数据库中的每个Schema创建第二个EDMX或第三个EDMX（就像举例一样）。

这样的分离将有助于组织您的EDMX，但它可以分离相同名称空间中实体的上下文。

此外，单独的EDMX文件可能会导致跨EDMX文件的JOIN操作导致冗余的冗余数据库通信。

但事实是，EDMX越大，使用越困难。确保它是正确的越困难。它更容易被打破。

您是否将您的EDMX文件分开？你有什么经验法则？

Answer 1

为分裂您的EDMX需要将 如果您有一个以上的项目，用一组实体的一个例子 而另一些具体项目，你愿意放弃具有之间的导航性能部分（并且只保留暴露的FK）。

如果您想分开维护EDMX，您可以自动合并EDMX，但可以向所有人开放一个上下文并将其作为一个查询。这要求他们共享相同的名称空间。

Answer 2

我们只需要在单个解决方案中使用两个单独的EDMX。 EDMX针对领域特定的模型实体发生了这种分离，另一种则发生在我们所有解决方案（支付作为示例）中更常见的情况。从逻辑上讲，您可以对我们说这是在数据库模式级别，尽管这不是分离的硬性规则。

虽然我们没有对它们进行连接的要求，但我们确实需要事务处理。我们用一个可重用的UnitOfWorkContainer来完成这个任务，这个UnitOfWorkContainer会将EF上下文包装在一个TransactionScope中。上下文将通过DI注入到容器中，如果容器中存在多个上下文，我们将只使用TransactionScope。

容器本身实现了我们的IUnitOfWork接口，所以它很容易插入到现有的代码库中。