我正在开发一个非常大的应用程序，其中包含 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，只对它需要的数据库子集进行建模。
但是，我们在创建 DbContexts 的方式上遇到了一个严重的问题。我们的模块不是完全独立的，也不是。有些包含从其他几个模块调用的操作。当它们存在时，它们需要参与调用模块启动的事务。（而且由于架构的原因，DTC 对我们来说不是一个选项。）在我们旧的 ADO 架构中，在模块之间传递开放连接以支持事务是没有问题的。
我查看了各种 DbContext 构造函数重载，并尝试从 EntityConnection 与 StoreConnection 管理事务，据我所知，没有任何组合可以允许 ModuleA 开始事务、调用 ModuleB 中的函数并拥有ModuleB 的 DbContext 参与事务。
它归结为两个简单的事情：
Case 1. 如果我用 DbContextA 的 EntityConnection 构建 DbContextB，则 DbContextB 不是用自己的模型元数据构建的；它重用 DbContextA 的元数据。由于上下文具有不同的 DbSet 集合，因此所有 ModuleB 的查询都会失败。（实体类型不是当前上下文的一部分。）
案例 2。如果我使用 ModuleA 的 StoreConnection 构造 DbContextB，DbContextB 无法识别 StoreConnection 在 EntityConnection 级别的打开事务，因此 EF 在 ModuleB 调用 SaveChanges() 时尝试启动新事务。由于数据库连接实际上有一个打开的事务，这会产生一个数据库异常。（连接不支持并行事务。）
有没有办法 1) 在案例 1 中强制 DbContextB 构建自己的模型，或者 2) 在案例 2 中让 DbContextB 的 ObjectContext 尊重其 StoreConnection 的事务状态？
（顺便说一句，我在 EF6 alpha 中看到了一些令人鼓舞的事情，但经过测试，发现唯一的区别是我可以在打开的连接上创建 DbContextB。但即便如此，上述 2 个问题仍然存在。）