Ninject - 實體框架 - 在運行期間更改上下文

Question

我們在這裏有一種有趣的情況。我們在Entity Framework中使用存儲庫模式，因此每個數據庫表都有自己的Repository類，它的構造函數中接受一個DbContext的實例。我們也在使用Ninject進行依賴注入。我們已經定義了一個在給定請求期間被實例化的單個上下文，以便當多個存儲庫請求一個DbContext時，同一個實例將在整個過程中使用。這使我們能夠遵循UnitOfWork模式，以便在多個存儲庫中可以發生多個事件，並且一次提交就會將所有更改提交到數據庫。

這是問題所在，我們還使用SQL Azure Federations將我們的客戶端數據分割成多個數據庫（分片）。我們需要能夠從同一請求中的一個聯合成員（數據庫）跳轉到另一個成員，但希望能夠使用依賴於注入上下文的相同服務/存儲庫方法。我們的第一個想法是隻在現有的上下文中執行USE FEDERATION sql命令來移動到下一個數據庫，但它有時似乎有效，而不是其他的。執行語句後，我們看到上下文中的底層連接確實指向新服務器，但由於某種原因，在該上下文上執行的查詢最終會返回上一個連接的結果。我認爲在多個數據庫上使用相同的上下文實例並不是真正支持的，因爲在連接到新數據庫時，通常會創建新的上下文。不幸的是，我們有一堆使用Ninject動態創建的存儲庫，然後它們接受相同的上下文實例，所以即使我們爲新數據庫啓動了新的上下文，我們也無法讓所有現有的存儲庫突然變爲取決於我們剛剛創建的新環境，而不是在初始請求時創建的環境。

這是我們能想到的，但不知道如何得到其中的任何工作了幾個解決方案：

1. 變化在現有環境中使用（如上解釋，但似乎沒有數據庫工作）
2. 換出一個新的所有庫注入情況下，使所有現有資源庫現在變得依賴於不同的環境
3. 不知從Ninject請求中的所有庫的傳遞所需的參數，一個新的實例上下文一旦被請求。

同樣，這裏的底線是我們有一組依賴單個上下文的存儲庫和服務，我們希望能夠重用這些服務和存儲庫，但是換出或更改上下文，是依賴的，指向一個新的服務器。

Answer 1

解決方案是讓Ninject完全脫離場景。不是最好的解決方案，但我們使用的工具並非真正按照我們想要的工作環境進行設計。