爲服務層設計DI（構造函數注入）庫

Question

我正在構建一個MVC3應用程序，試圖使用IoC和構造函數注入。我的數據庫（目前爲止）大約有50個表。我使用EF4（w/POCO T4模板）作爲我的DAC代碼。我正在使用存儲庫模式，每個表都有自己的存儲庫。我的服務層中的服務類被注入到這些存儲庫中。

問題：我的服務類越來越多，他們需要的存儲庫。在某些情況下，我正在接近10個儲存庫，並開始聞起來。

是否有一種常見的方法來設計存儲庫和服務類，使服務不需要這麼多的存儲庫？

這裏有我的想法，我只是不知道哪一個是正確的：

1）這是一個跡象，我應該考慮合併/編組我的倉庫到表中的相關部分，減少的數量或依賴庫每服務類別。但是，這種方法的問題在於它會使我的存儲庫膨脹並使其複雜化，並使我無法爲所有存儲庫（數據檢索/更新的標準方法）使用通用接口。

2）這是一個標誌，我應該考慮根據我的存儲庫（表格）將我的服務分成組。問題在於我的一些服務方法共享通用實現，並且在類之間打破這些方法可能會使我的依賴關係複雜化。

3）這是一個跡象，我不知道我在做什麼，並有一些根本錯誤，我甚至無法看到。

UPDATE：對於我如何實現EF4和資料庫的想法，請在CodePlex上this sample app（我用version 1）。然而，看看那裏（和這裏）的一些評論，看起來像我需要做更多的閱讀，以確保這是我想要採取的路線 - 聽起來可能不是。

Answer 1

Chandermani is right你的一些表可能不是核心領域類。這意味着除了單一類型的父實體之外，您不會搜索該數據。在這些情況下，您可以將它們視爲「複雜類型」而不是全面實體，而EF仍將照顧您。

我使用存儲庫模式，每個表都有自己的倉庫

我希望你沒有這些你自己從頭開始編寫。

EF 4.1已經實施the Repository Pattern（DbSet）和the Unit of Work pattern（DbContext）。舊版本也是如此，儘管通過將這些屬性更改爲IDbSet，可以輕鬆調整DbContext模板以提供乾淨的可模仿實現。

雖然我看過幾篇教程文章，但人們仍然在寫自己的文章。這對我來說很奇怪，因爲他們通常不提供理由，除了他們「實施存儲庫模式」這一事實。

爲訪問方法（如FindById）爲這些存儲庫編寫包裝會使訪問變得稍微容易一些，但正如您所看到的，付出的努力可能很少，可能回報很少。就個人而言，除非我發現有一些有趣的領域邏輯或複雜的查詢需要封裝，否則我甚至不會直接對IDbSet使用Linq。

我的服務層中的服務類被注入到這些存儲庫中。

即使您選擇使用自定義查詢包裝，你可以選擇簡單地注入DbContext，並讓服務代碼實例，它需要的包裝。你仍然能夠嘲笑你的數據訪問層，你將無法模擬包裝代碼。儘管如此，我仍然建議你注入一些不太通用的東西，因爲複雜的實現正是你希望能夠在維護中進行分解的類型，或者用模擬代替。

Answer 2

如果你看DDD Aggregate Root模式，並嘗試在這個角度看你的數據，你會意識到，許多表沒有獨立的存在。他們的數據僅在父母的情況下有效。他們的大部分操作都需要您獲取父項。如果可以將這些表分組並找到父實體\存儲庫，則可以刪除所有其他子存儲庫。將父母孩子關聯起來的複雜性直到現在您將在業務層中進行（假設您正在使用獨立回購檢索父母和孩子）不會轉移到DAL

重構服務界面也是一個可行的選擇，和任何常見的功能可以被移動到一個基類和/或可以被定義爲一種服務，它是由您所有的現有服務（是A和有A）

Answer 3

@Chandermani有一個關於聚合根的好點。存儲庫不應該需要與表格進行1：1映射。

獲取大量的依賴注入是一個很好的跡象，你的服務做得太多。遵循單一職責原則，並將其重構爲更易於管理的部分。

Answer 4

是您的服務寫入所有的存儲庫？我發現我的服務與存儲庫非常接近，它們提供了存儲庫公開的CRUD操作的業務邏輯。