我们这里有一个有趣的情况。我们将存储库模式与 Entity Framework 一起使用，因此每个数据库表都有自己的 Repository 类，该类在其构造函数中接受 DbContext 的实例。我们还使用 Ninject 进行依赖注入。我们已经定义了在给定请求期间要实例化的单个上下文，以便当多个存储库请求 DbContext 时，始终使用相同的实例。这允许我们遵循 UnitOfWork 模式，因此可以在多个存储库上发生多件事，并且一次提交将提交所有更改到数据库。
这就是问题所在，我们还使用 SQL Azure Federations，它将我们的客户端数据拆分为多个数据库（分片）。我们需要能够在同一个请求中从一个联合成员（数据库）跳转到另一个，但希望能够使用依赖于注入上下文的相同服务/存储库方法。我们的第一个想法是仅在现有上下文上执行 USE FEDERATION sql 命令以移动到下一个数据库，但它似乎有时有效，而其他情况则无效。执行该语句后，我们看到上下文上的底层连接确实指向新服务器，但由于某种原因，在该上下文上执行的查询最终会返回前一个连接的结果。我认为在多个数据库上使用相同的上下文实例并不是真正原生支持的，因为您通常会在连接到新数据库时启动新上下文。不幸的是，我们有一堆使用 Ninject 动态创建的存储库，然后它们接收相同的上下文实例，因此即使我们确实为新数据库启动了一个新上下文，我们也无法让所有现有的存储库突然变成取决于我们刚刚启动的新上下文，而不是在初始请求中创建的上下文。
以下是我们可以想到的一些解决方案，但不确定如何使它们中的任何一个起作用：
- 更改在现有上下文中使用的数据库（如上所述，但似乎不起作用）
- 将所有存储库的注入上下文替换为新的，以便所有现有存储库现在都依赖于不同的上下文
- 以某种方式从 Ninject 请求所有存储库的新实例，该实例在请求时传递上下文所需的参数。
同样，这里的底线是我们有一组依赖于单个上下文的存储库和服务，我们希望能够重用这些服务和存储库，但交换或更改所有依赖的上下文，以指向一个新的服务器。