设计决策:多个EF EDMX文件

Question

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

当它变大时，很容易创建第二个EDMX或第三个--甚至为数据库中的每个Schema创建一个EDMX(就像一个例子)。

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

此外，分离的EDMX文件可能会造成一种情况，即跨EDMX文件的联接操作会导致过多的冗余数据库通信。

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

--你把你的EDMX文件拆开了吗？你有什么时候去的经验法则吗？

Answer 1

需要拆分EDMX的一个例子是，如果您有一组在多个项目中使用的实体，而其他实体是特定于项目的，并且您愿意放弃在部件之间拥有导航属性(并且只保留公开的FKs)。

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

Answer 2

我们只需要在一个解决方案中使用两个单独的EDMX。这种分离发生在我们的领域特定模型实体的EDMX和在我们的所有解决方案中更常见的那些实体(支付作为一个例子)。从逻辑上说，对于我们来说，这是在db模式级别，尽管这不是分离的硬规则。

虽然我们没有加入他们的要求，但我们确实需要交易。我们通过一个可重用的UnitOfWorkContainer实现了这一点，该TransactionScope将EF上下文包装在TransactionScope中。上下文将通过DI注入容器，并且只有当容器中包含多个上下文时，我们才会使用TransactionScope。

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