使用彈簧DI無界面是否正確

我正在使用彈簧依賴注入，其中我可以通過一些外部xml文件注入對象依賴關係。使用彈簧DI無界面是否正確

我的問題是：

是不是蠻好用的彈簧DI不使用接口？

因爲與DI，我們要做到一兩件事：

如果一個類是由具有相同的方法，但不同定義的一些其他類的替代，那麼我們就需要在代碼中的任何改變這個類正在被引用。

這很好，如果我使用接口作爲接口可以指向任何正在實現此接口的類，但如果我直接通過DI注入類對象，那麼DI沒有意義，因爲在這種情況下，如果類被替換，我必須在我們的代碼被引用的地方更改代碼。

如果出現問題，請讓我糾正。

比方說，我有

Class Datasource{ 

    String url; 
    String user; 
    String database; 

}

現在我使用它，而不DI爲

Class Abc{ 

    Datasource datasource = new Datasource(); 
}

什麼在這個問題，什麼是我可以，如果我使用DI的好處。

獲得單身物件唯一目標的DI？

來源

2014-10-09 Ankit Gupta

這不是你想用依賴注入實現的事情。您想要將配置相關對象（即使用存儲庫的服務）。 DI與能夠替換依賴關係無關。無論使用接口還是不使用接口，Dependeny Injection都可以並且可以工作。 – 2014-10-09 10:33:24

我們沒有提到XML中的接口，而是類。在實時應用程序中，類很少被替換或與其他類交換。並且DI不是「如果一個班正在重新......」 – Jaikrat 2014-10-09 10:33:43

@ M.Deinum如果DI不是「如果一個班級......」那麼DI有什麼好處，爲什麼我應該將控制外化？ – 2014-10-09 10:46:22

依賴注入不是關於接口或類或枚舉或...它是關於Inversion of Control。

想象下面的類。

public class PersonService { 

    private PersonRepository repository = new PersonRepository(); 
}

顯然這沒什麼不對。然而，如果PersonRepository需要其他依賴關係，那麼如果它將另一個複雜對象作爲構造參數呢？突然之間PersonService是如何構建一個對象及其所有依賴關係的邏輯。而它只想使用該對象。

public class PersonService { 

    private PersonRepository repository; 

    public PersonService() { 
     InitialContext ctx = new InitialContext(); 
     repository = ctx.lookup("java:comp/env/repositories/person"); 
    } 
}

上面的代碼綁定到JNDI，你怎麼測試它（容易），當然也可以構建自己的模擬JNDI服務和預配置與構建的或嘲笑庫但這是相當麻煩。

public class PersonService { 

     private final PersonRepository repository; 
     public PersonService(PersonRepository repository) { 
      this.repository=repository; 
     } 
}

以上，使基本千方百計，對如何構建它只是遞給了PersonRepository，它來自哪裏並不重要的PersonService沒有burder。它是實際的類還是（基於類的）代理，並不在意。

因此，依賴注入，你想把PersonRepository用於PersonService它應該無關緊要它來自哪裏，它是如何構造的，或者它是否是一個實際對象的代理。它只需要一個PersonRepository。

來源

2014-10-09 11:30:59

感謝您的回答，它是有道理的，對象創建有點複雜的任務，然後應該使用DI，但我已經看到許多項目，像新的Abc（）一樣直觀的對象創建，仍然有人使用DI來注入Abc 。 – 2014-10-09 11:54:59

這不是關於簡單性，而是關於責任......它不是「PersonService」構造所需引用對象的責任。只要把它們給對象。 – 2014-10-09 11:58:20

完全信服，非常感謝 – 2014-10-09 12:06:03

使用彈簧DI無界面是否正確

回答

相關問題