Entity framework 设计决策：多个EF EDMX文件

如果您使用过实体框架，那么您就知道EDMX很酷。你也知道它会变得巨大，几乎无法管理

当它变大时，很容易为数据库中的每个模式创建第二个或第三个EDMX，甚至是一个（作为示例）

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

此外，单独的EDMX文件可能会造成跨EDMX文件的联接操作导致过度冗余的数据库通信的情况

但是，事实仍然是，EDMX越大，使用起来就越困难。确保它是正确的就越困难。越容易打破

---

是否将EDMX文件分开？您对何时使用它有经验法则吗？

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

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

---

容器本身实现了我们的IUnitOfWork接口，因此很容易插入现有的代码库

需要拆分EDMX的一个例子是 如果有一组实体在多个项目中使用， 而另一些是特定于项目的，并且您愿意放弃零件之间的导航属性（而只保留暴露的FK）

---

如果要单独维护，可以将EDMx自动合并为一个，但要为它们打开一个上下文并作为一个查询。这要求它们共享相同的名称空间。

我明白了；跨项目重用EDMX。这是拆分EDMX的合理理由。我们自己还没有达到这种情况。