Question

We have kind of an interesting situation here. We are using the repository pattern with Entity Framework so each database table has its own Repository class that accepts an instance of a DbContext in its constructor. We are also using Ninject for dependency injection. We have defined a single context to be instantiated during a given request so that when a multiple of repositories ask for a DbContext, the same instance is used throughout. This allows us to follow a UnitOfWork pattern so multiple things can occur on multiple repositories and a single commit will commit all changes to the database.

Here is the issue, we are also using SQL Azure Federations which splits up our client data into multiple databases (sharding). We need to be able to jump from one federation member (database) to another within the same request but want to be able to use the same service/repository methods that are dependent upon the injected context. Our first thought was to just execute the USE FEDERATION sql command on the existing context to move to the next database but it seems to work sometimes and not others. After executing the statement we see that the underlying connection on the context really is pointing to the new server but for some reason queries executed on that context end up returning results from the previous connection. I presume using the same instance of a context on multiple database is not something that is really natively supported as you would normally spin up a new context when connecting to a new database. Unfortunately we have a bunch of repositories that are created dynamically using Ninject which then take in the same instance of the context so even if we do spin up a new context for the new database, we have no way to making all the existing repositories suddenly become dependent upon the new context we just spun up instead of the one that was created at the initial request.

Here are a few solutions we can think of but are not sure how to get any of them to work:

  1. Change the database used on an existing context (as explained above but didn't seem to work)
  2. Swap out an injected context for all repositories with a new one so that all existing repositories now become dependent upon a different context
  3. Somehow request from Ninject a new instance of all the repositories passing in the parameters needed for the context once it is requested.

Again, bottom line here is we have a set of repositories and services that are dependent upon a single Context and we want to be able to reuse those services and repositories but swap out or change the context, on which all are dependent, to point to a new server.

Was it helpful?

Solution

Solution was to just completely drop Ninject out of the scenario. Not the best solution but the tools we are using were not really designed to do what we wanted in the environment we are working.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top