本章的內容主要是想探討咱們在進行Spring 開發過程中,關於依賴注入的幾個知識點。感興趣的讀者能夠先看下如下問題:html
@Autowired
, @Resource
, @Inject
三個註解的區別@Autowired
時,是否有出現過Field injection is not recommended
的警告?你知道這是爲何嗎?若是你對上述問題都瞭解,那我我的以爲你的開發經驗應該是不錯的👍。java
下面咱們就依次對上述問題進行解答,而且總結知識點。git
@Autowired
, @Resource
, @Inject
三個註解的區別Spring 支持使用@Autowired
, @Resource
, @Inject
三個註解進行依賴注入。下面來介紹一下這三個註解有什麼區別。github
@Autowired
爲Spring 框架提供的註解,須要導入包org.springframework.beans.factory.annotation.Autowired
。spring
這裏先給出一個示例代碼,方便講解說明:app
public interface Svc {
void sayHello();
}
@Service
public class SvcA implements Svc {
@Override
public void sayHello() {
System.out.println("hello, this is service A");
}
}
@Service
public class SvcB implements Svc {
@Override
public void sayHello() {
System.out.println("hello, this is service B");
}
}
@Service
public class SvcC implements Svc {
@Override
public void sayHello() {
System.out.println("hello, this is service C");
}
}
複製代碼
測試類:框架
@SpringBootTest
public class SimpleTest {
@Autowired
// @Qualifier("svcA")
Svc svc;
@Test
void rc() {
Assertions.assertNotNull(svc);
svc.sayHello();
}
}
複製代碼
裝配順序:ide
按照type
在上下文中查找匹配的bean單元測試
查找type爲Svc的bean
複製代碼
若是有多個bean,則按照name
進行匹配測試
若是有@Qualifier
註解,則按照@Qualifier
指定的name
進行匹配
查找name爲svcA的bean
複製代碼
若是沒有,則按照變量名進行匹配
查找name爲svc的bean
複製代碼
匹配不到,則報錯。(@Autowired(required=false)
,若是設置required
爲false
(默認爲true
),則注入失敗時不會拋出異常)
在Spring 的環境下,@Inject
和@Autowired
是相同的,由於它們的依賴注入都是使用AutowiredAnnotationBeanPostProcessor
來處理的。
@Inject
是 JSR-330 定義的規範,若是使用這種方式,切換到Guice
也是能夠的。
Guice 是 google 開源的輕量級 DI 框架
若是硬要說兩個的區別,首先@Inject
是Java EE包裏的,在SE環境須要單獨引入。另外一個區別在於@Autowired
能夠設置required=false
而@Inject
並無這個屬性。
@Resource
是JSR-250定義的註解。Spring 在 CommonAnnotationBeanPostProcessor
實現了對JSR-250
的註解的處理,其中就包括@Resource
。
@Resource
有兩個重要的屬性:name
和type
,而Spring 將@Resource
註解的name
屬性解析爲bean的名字,而type
屬性則解析爲bean的類型。
裝配順序:
name
和type
,則從Spring上下文中找到惟一匹配的bean進行裝配,找不到則拋出異常。name
,則從上下文中查找名稱(id)匹配的bean進行裝配,找不到則拋出異常。type
,則從上下文中找到類型匹配的惟一bean進行裝配,找不到或是找到多個,都會拋出異常。name
,又沒有指定type
,則默認按照byName
方式進行裝配;若是沒有匹配,按照byType
進行裝配。Field injection is not recommended
在使用IDEA 進行Spring 開發的時候,當你在字段上面使用@Autowired
註解的時候,你會發現IDEA 會有警告提示:
Field injection is not recommended
Inspection info: Spring Team Recommends: "Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies".
翻譯過來就是這個意思:
不建議使用基於 field 的注入方式。
Spring 開發團隊建議:在你的Spring Bean 永遠使用基於constructor 的方式進行依賴注入。對於必須的依賴,永遠使用斷言來確認。
好比以下代碼:
@Service
public class HelpService {
@Autowired
@Qualifier("svcB")
private Svc svc;
public void sayHello() {
svc.sayHello();
}
}
public interface Svc {
void sayHello();
}
@Service
public class SvcB implements Svc {
@Override
public void sayHello() {
System.out.println("hello, this is service B");
}
}
複製代碼
將光標放到@Autowired
處,使用Alt + Enter
快捷進行修改以後,代碼就會變成基於Constructor的注入方式,修改以後:
@Service
public class HelpService {
private final Svc svc;
@Autowired
public HelpService(@Qualifier("svcB") Svc svc) {
// Assert.notNull(svc, "svc must not be null");
this.svc = svc;
}
public void sayHello() {
svc.sayHello();
}
}
複製代碼
若是按照Spring 團隊的建議,若是svc
是必須的依賴,應該使用Assert.notNull(svc, "svc must not be null")
來確認。
修正這個警告提示當然簡單,可是我以爲更重要是去理解爲何Spring 團隊會提出這樣的建議?直接使用這種基於 field 的注入方式有什麼問題?
首先咱們須要知道,Spring 中有這麼3種依賴注入的方式:
所謂基於 field 注入,就是在bean的變量上使用註解進行依賴注入。本質上是經過反射的方式直接注入到field。這是我日常開發中看的最多也是最熟悉的一種方式,同時,也正是 Spring 團隊所不推薦的方式。好比:
@Autowired
private Svc svc;
複製代碼
經過對應變量的setXXX()
方法以及在方法上面使用註解,來完成依賴注入。好比:
private Helper helper;
@Autowired
public void setHelper(Helper helper) {
this.helper = helper;
}
複製代碼
注:在
Spring 4.3
及之後的版本中,setter 上面的@Autowired
註解是能夠不寫的。
將各個必需的依賴所有放在帶有註解構造方法的參數中,並在構造方法中完成對應變量的初始化,這種方式,就是基於構造方法的注入。好比:
private final Svc svc;
@Autowired
public HelpService(@Qualifier("svcB") Svc svc) {
this.svc = svc;
}
複製代碼
在
Spring 4.3
及之後的版本中,若是這個類只有一個構造方法,那麼這個構造方法上面也能夠不寫@Autowired
註解。
正如你所見,這種方式很是的簡潔,代碼看起來很簡單,通俗易懂。你的類能夠專一於業務而不被依賴注入所污染。你只須要把@Autowired
扔到變量之上就行了,不須要特殊的構造器或者set方法,依賴注入容器會提供你所需的依賴。
成也蕭何敗也蕭何
基於 field 注入雖然簡單,可是卻會引起不少的問題。這些問題在我日常開發閱讀項目代碼的時候就常常碰見。
容易違背了單一職責原則 使用這種基於 field 注入的方式,添加依賴是很簡單的,就算你的類中有十幾個依賴你可能都以爲沒有什麼問題,普通的開發者極可能會無心識地給一個類添加不少的依賴。可是當使用構造器方式注入,到了某個特定的點,構造器中的參數變得太多以致於很明顯地發現something is wrong。擁有太多的依賴一般意味着你的類要承擔更多的責任,明顯違背了單一職責原則(SRP:Single responsibility principle)。
這個問題在我司的項目代碼真的很常見。
依賴注入與容器自己耦合
依賴注入框架的核心思想之一就是受容器管理的類不該該去依賴容器所使用的依賴。換句話說,這個類應該是一個簡單的POJO(Plain Ordinary Java Object)可以被單獨實例化而且你也能爲它提供它所需的依賴。
這個問題具體能夠表如今:
不能使用屬性注入的方式構建不可變對象(final
修飾的變量)
Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration methods for optional dependencies.
簡單來講,就是
強制依賴就用構造器方式
可選、可變的依賴就用setter 注入
固然你能夠在同一個類中使用這兩種方法。構造器注入更適合強制性的注入旨在不變性,Setter注入更適合可變性的注入。
讓咱們看看Spring 這樣推薦的理由,首先是基於構造方法注入,
The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state. As a side note, a large number of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.
Spring 團隊提倡使用基於構造方法的注入,由於這樣一方面能夠將依賴注入到一個不可變的變量中 (注:final
修飾的變量),另外一方面也能夠保證這些變量的值不會是 null。此外,通過構造方法完成依賴注入的組件 (注:好比各個 service
),在被調用時能夠保證它們都徹底準備好了。與此同時,從代碼質量的角度來看,一個巨大的構造方法一般表明着出現了代碼異味,這個類可能承擔了過多的責任。
而對於基於 setter 的注入,他們是這麼說的:
Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection later.
基於 setter 的注入,則只應該被用於注入非必需的依賴,同時在類中應該對這個依賴提供一個合理的默認值。若是使用 setter 注入必需的依賴,那麼將會有過多的 null 檢查充斥在代碼中。使用 setter 注入的一個優勢是,這個依賴能夠很方便的被改變或者從新注入。
以上就是本文的全部內容,但願閱讀本文以後能讓你對Spring 的依賴注入有更深的理解。
若是本文有幫助到你,但願能點個贊,這是對個人最大動力🤝🤝🤗🤗。