设计决策：多个 EF EDMX 文件
如果您使用过实体框架，那么您就会知道 EDMX 很酷。您也知道它可能会变得巨大且几乎难以管理。
当它变大时，很容易创建第二个或第三个 EDMX - 甚至为数据库中的每个架构创建一个（仅作为示例）。
这种分离有助于组织 EDMX，但它可能会分离同一命名空间中实体的上下文。
此外，单独的 EDMX 文件可能会造成跨 EDMX 文件的 JOIN 操作导致过多、冗余的数据库通信的情况。
但事实是，EDMX 越大，使用起来就越困难。越难保证其正确性。越容易破裂。
您是否将 EDMX 文件分开？您对于何时进行此操作有经验法则吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
需要拆分 EDMX 的一个例子是
如果您有一组在多个项目中使用的实体，
而其他的是特定于项目的，您愿意放弃部件之间的导航属性（并保留仅暴露的 FK）。
如果您想单独维护 EDMX，但要向所有 EDMX 打开上下文并作为一个整体进行查询，则可以自动将 EDMX 合并为一个。这要求它们共享相同的命名空间。
One example for the need to split your EDMX would be
if you have a group of entities that are used in more than one project,
while others are project-specific and you are willing to forsake having navigation properties between the parts (and remain with only exposed FKs).
You can automatically merge the EDMXs into one if you want to maintain the separately, but open up a context to them all and query as one. This requires that they share the same namespace.
我们仅需要在单个解决方案中使用两个单独的 EDMX。这种分离发生在我们身上，一个 EDMX 用于特定领域的模型实体，另一个用于我们所有解决方案中更常见的实体（以支付为例）。从逻辑上讲，您可以说这对我们来说是在数据库模式级别，尽管这不是分离的硬性规则。
虽然我们不需要跨它们连接，但我们确实需要事务。我们通过可重用的 UnitOfWorkContainer 来实现这一点，它将 EF 上下文包装在 TransactionScope 内。上下文将通过 DI 注入到容器中，并且只有在容器中保存多个上下文时我们才会使用 TransactionScope。
容器本身实现了我们的 IUnitOfWork 接口，因此很容易插入现有的代码库。
We've only gone as far as needing to use two separate EDMX in a single solution. This separation occurred for us with an EDMX for domain specific model entities and another for those more common across all of our solutions (Payment as an example). Logically you could say this for us was at the db schema level although that wasn't the hard rule of the separation.
Whilst we didn't have a requirement for joins across them we did need transactions. We accomplished this with a reusable UnitOfWorkContainer that would wrap the EF contexts within a TransactionScope. The contexts would be injected through DI into the container and we would only use the TransactionScope if there was more than one context held in the container.
The container itself implemented our IUnitOfWork interface so it was dead easy to plug into the existing codebase.