设计决策：多个EF EDMX文件

Question

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

当它变大时，很有可能创建第二个EDMX或第三个 - 甚至一个用于数据库中的每个Schema（仅作为示例）。

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

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

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

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

Answer 1

我们只需要在一个解决方案中使用两个独立的EDMX。对于我们而言，这种分离对于我们来说是针对特定领域的模型实体的EDMX，而另一种是针对我们所有解决方案中更常见的那些（以支付为例）。从逻辑上讲，你可以说这对我们来说是在数据库架构级别，尽管这不是分离的硬规则。

虽然我们没有要求加入他们，但我们确实需要交易。我们使用可重用的UnitOfWorkContainer实现了这一点，它将在TransactionScope中包装EF上下文。上下文将通过DI注入到容器中，如果容器中保存了多个上下文，我们只会使用TransactionScope。

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

Answer 2

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

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