【发布时间】：2013-05-24 19:48:11
【问题描述】：
我正在开发一个包含 100 多个模块和数据库中近 500 个表的大型应用程序。我们正在使用 Entity Framework 4.2 Code First 将此应用程序转换为 WPF/WCF。我们的数据库是 SQL Anywhere 11。由于数据库的大小，我们使用类似于 Bounded DbContexts 的方法，如 Julie Lerman 的 http://msdn.microsoft.com/en-us/magazine/jj883952.aspx 所述。 我们的每个模块都创建了自己的 DbContext，只对它需要的数据库子集进行建模。
但是，我们在创建 DbContext 的方式上遇到了一个严重的问题。我们的模块不是完全独立的，也不是。有些包含从其他几个模块调用的操作。当它们存在时，它们需要参与调用模块启动的事务。 （而且由于架构的原因，DTC 对我们来说不是一个选项。）在我们旧的 ADO 架构中，在模块之间传递开放连接以支持事务是没有问题的。
我查看了各种 DbContext 构造函数重载，并尝试从 EntityConnection 与 StoreConnection 管理事务，据我所知，没有任何组合允许 ModuleA 开始事务，调用 ModuleB 中的函数，并让 ModuleB 的 DbContext 参与事务。
归结为两个简单的事情：
Case 1. 如果我用 DbContextA 的 EntityConnection 构建 DbContextB，则 DbContextB 不是用自己的模型元数据构建的；它重用 DbContextA 的元数据。由于上下文具有不同的 DbSet 集合，因此所有 ModuleB 的查询都会失败。 （实体类型不是当前上下文的一部分。）
案例 2。如果我使用 ModuleA 的 StoreConnection 构造 DbContextB，则 DbContextB 在 EntityConnection 级别无法识别 StoreConnection 的打开事务，因此 EF 在 ModuleB 调用 SaveChanges() 时尝试启动新事务。由于数据库连接实际上有一个打开的事务，这会产生一个数据库异常。 （连接不支持并行事务。）
有什么方法可以 1）在案例 1 中强制 DbContextB 构建自己的模型，或 2）在案例 2 中让 DbContextB 的 ObjectContext 尊重其 StoreConnection 的事务状态？
（顺便说一句，我在 EF6 alpha 中看到了一些令人鼓舞的东西，但经过测试，发现唯一的区别是我可以在打开的连接上创建 DbContextB。但即便如此，上述 2 个问题仍然存在。 )
【问题讨论】：
标签： entity-framework transactions dbcontext bounded-contexts