5

If you have used the Entity Framework then you know the EDMX is cool. You also know it can become HUGE and almost unmanageable.

When it gets large, it is tempting to create a second EDMX or third - even one for each Schema in your database (just as an example).

Such a seperation would help with organization of your EDMX, but it could seperate the context of entities in the same namespace.

Moreover, seperate EDMX files can create a situation where a JOIN operation across EDMX files results in excessive, redundant database communication.

But, the fact remains, the larger the EDMX, the more difficult it is to use. The more difficult it is to ensure it is correct. The easier it is to break.

Do you break your EDMX files apart? Do you have a rule of thumb for when to it?

4

2 回答 2

1

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

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

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

于 2011-06-24T22:05:18.787 回答
1

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

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

于 2011-06-25T00:57:21.203 回答