使用DI框架時，新服務如何知道其他服務可用？

Question

在一個使用DI框架的大型項目中（例如Ninject），在實現一個新的「服務」以找出可用作依賴關係的其他「服務」時，存在哪些選項。在使用DI之前，我注意到在我們的代碼庫中有一種傾向，即獲得對可以訪問所有可用功能的「上帝」對象的引用，然後Visual Studio的智能感知對於發現所有可用功能變得非常有用（顯然這是方法是唯一可能的，因爲首先有這樣一個對象的建築決策很差）。

我所能一些可能的答案，有興趣什麼爲他人工作：

1. 你應該知道你正在工作的不夠好， 知道其他類/存在服務（例如整個系統，如果我有 靜態類，我只需要知道他們存在能夠 使用它們）。
2. 您保持良好的 代碼庫的外部文檔，以便所有的開發人員都能理解所有的類/服務 （這給我帶來了很大的文檔負擔）。
3. 創建一個API來查詢DI容器（Ninject內核）中所有綁定的列表 ，以查看哪些服務可用（可能只有 單身人士）。這也可以作爲構建系統的一部分完成， 在開發者 可以參考的每個構建上自動生成文檔。

這對於其他開發者來說有沒有問題？

Answer 1

通常情況下，您不希望看到系統中存在的所有服務，然後選擇其中一個服務。你想要訪問一個功能所有權。以某種方式用名稱空間來組織您的類，以便在哪裏尋找它。

E.g.如果我想知道.NET中可用的集合，我輸入System.Collections.Generic.，智能感知給我一個選項列表。

Answer 2

我傾向於組織我的代碼庫，以便我有一箇中心的「接口」項目，所有其他項目都有參考。然後我的Logger只能通過​​接口使用，並且日誌模塊可以選擇提供哪個具體的​​。你不應該要求具體的課程 - 這打破了DI的目的。

一般而言，當您正在實施新服務時，您應該已知道您需要的依賴關係。如果你不知道你應該使用什麼，問誰做。這相當於有足夠的文檔 - 依靠智能感知會給你一個非常淺的想法，你應該把它當作依賴。相反，您應該諮詢文件或瞭解該地區的人員。