Ninject - 实体框架 - 在运行期间更改上下文

Question

我们在这里有一种有趣的情况。我们在Entity Framework中使用存储库模式，因此每个数据库表都有自己的Repository类，它的构造函数中接受一个DbContext的实例。我们也在使用Ninject进行依赖注入。我们已经定义了一个在给定请求期间被实例化的单个上下文，以便当多个存储库请求一个DbContext时，同一个实例将在整个过程中使用。这使我们能够遵循UnitOfWork模式，以便在多个存储库中可以发生多个事件，并且一次提交就会将所有更改提交到数据库。

这是问题所在，我们还使用SQL Azure Federations将我们的客户端数据分割成多个数据库（分片）。我们需要能够从同一请求中的一个联合成员（数据库）跳转到另一个成员，但希望能够使用依赖于注入上下文的相同服务/存储库方法。我们的第一个想法是只在现有的上下文中执行USE FEDERATION sql命令来移动到下一个数据库，但它有时似乎有效，而不是其他的。执行语句后，我们看到上下文中的底层连接确实指向新服务器，但由于某种原因，在该上下文上执行的查询最终会返回上一个连接的结果。我认为在多个数据库上使用相同的上下文实例并不是真正支持的，因为在连接到新数据库时，通常会创建新的上下文。不幸的是，我们有一堆使用Ninject动态创建的存储库，然后它们接受相同的上下文实例，所以即使我们为新数据库启动了新的上下文，我们也无法让所有现有的存储库突然变为取决于我们刚刚创建的新环境，而不是在初始请求时创建的环境。

这是我们能想到的，但不知道如何得到其中的任何工作了几个解决方案：

1. 变化在现有环境中使用（如上解释，但似乎没有数据库工作）
2. 换出一个新的所有库注入情况下，使所有现有资源库现在变得依赖于不同的环境
3. 不知从Ninject请求中的所有库的传递所需的参数，一个新的实例上下文一旦被请求。

同样，这里的底线是我们有一组依赖单个上下文的存储库和服务，我们希望能够重用这些服务和存储库，但是换出或更改上下文，是依赖的，指向一个新的服务器。

Answer 1

解决方案是让Ninject完全脱离场景。不是最好的解决方案，但我们使用的工具并非真正按照我们想要的工作环境进行设计。