如何使用依賴解析器？

Question

我有一個小問題。對於無損架構，我使用依賴注入。 如何在我的其他類之間共享此依賴關係解析器？這個解析器應該是一個帶有一些實例的全局靜態列表的靜態類，或者我應該這樣做非靜態的，並將此解析器通過屬性或構造函數傳遞給其他類？我認爲，你應該做這個非靜態的，因爲如果你用一個單獨的靜態解析器來做這件事，那麼你對這個解析器有依賴性。

Answer 1

你可以有兩種類型的解析器。

• 一個地方你的依賴被使用的構造像解決：

  MyClass myClass; 
  public MyConstructor(MyClass myClass) { 
      this.myClass = myClass; 
  } 
  

• 或者另一種方法是使用setter方法就像使用setter注入：

  public void setMyClass(MyClass myClas) { 
      this.myClass = myClass; 
  } 
  

有其他設計模式（如工廠或單件）使用靜態方法並基於它們生成的輸入參數不同的對象，你可以使用，但它完全不同於DI，可以幫助DI。

Answer 2

很多已經說和寫這一點，但普遍的共識是，有一個全球性的「分解」（又名Service Locator pattern）是anti-pattern：

與服務定位器的問題是，它隱藏一個類' 依賴關係，導致運行時錯誤，而不是編譯時錯誤， ，以及使代碼更難以維護，因爲它會變得不清楚，當你將引入一個突破性的變化。

而不是使用這個全局解析器，你應該使用oposite模式：依賴注入（DI）。使用DI，您可以將依賴關係注入到類中，而不是讓類通過某個解析器請求依賴關係。最常見的 - 通常最好的方法是使用構造函數注入。這意味着某些類的構造函數在類sole constructor中定義了它作爲構造函數參數所需的依賴關係。

類的構造函數應該只包含這個類直接使用的依賴項。類依賴關係所需的依賴關係不應暴露給該類，因爲這隻會不必要地增加代碼的耦合性，並使代碼難以測試，難以推理。

這樣的結果是，應用程序中的非類將負責構建和請求它們的依賴關係。每個類將這個責任推到調用鏈上，導致在應用程序中有一個位置，靠近應用程序的啓動路徑，負責構建所有對象圖：composition root。

構圖根是您可以使用這樣的解析器的地方，但這是可選的。