国产精品久久久aaaa,日日干夜夜操天天插,亚洲乱熟女香蕉一区二区三区少妇,99精品国产高清一区二区三区,国产成人精品一区二区色戒,久久久国产精品成人免费,亚洲精品毛片久久久久,99久久婷婷国产综合精品电影,国产一区二区三区任你鲁

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

Spring開發過程中依賴注入的幾個知識點

5jek_harmonyos ? 來源:掘金 ? 作者:Richard_Yi ? 2021-08-27 09:18 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

轉自丨https://juejin.cn/post/6844904056230690824

本章的內容主要是想探討我們在進行 Spring 開發過程當中,關于依賴注入的幾個知識點。感興趣的讀者可以先看下以下問題:

@Autowired,@Resource,@Inject 三個注解的區別

當你在使用@Autowired時,是否有出現過Field injection is not recommended的警告?你知道這是為什么嗎?

Spring 依賴注入有哪幾種方式?官方是怎么建議使用的呢?

如果你對上述問題都了解,那我個人覺得你的開發經驗應該是不錯的。

下面我們就依次對上述問題進行解答,并且總結知識點。

@Autowired,@Resource,@Inject 三個注解的區別

Spring 支持使用@Autowired, @Resource, @Inject 三個注解進行依賴注入。下面來介紹一下這三個注解有什么區別。

@Autowired

@Autowired為Spring 框架提供的注解,需要導入包org.springframework.beans.factory.annotation.Autowired。

這里先給出一個示例代碼,方便講解說明:

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(); } }

裝配順序:

按照type在上下文中查找匹配的bean

查找type為Svc的bean

如果有多個bean,則按照name進行匹配

如果有@Qualifier注解,則按照@Qualifier指定的name進行匹配

查找name為svcA的bean

如果沒有,則按照變量名進行匹配

查找name為svc的bean

匹配不到,則報錯。(@Autowired(required=false),如果設置required為false(默認為true),則注入失敗時不會拋出異常)

@Inject

在 Spring 的環境下,@Inject和@Autowired 是相同的,因為它們的依賴注入都是使用AutowiredAnnotationBeanPostProcessor來處理的。

@Inject是 JSR-330 定義的規范,如果使用這種方式,切換到Guice也是可以的。

?“Guice 是 google 開源的輕量級 DI 框架”?

如果硬要說兩個的區別,首先@Inject是 Java EE 包里的,在 SE 環境需要單獨引入。另一個區別在于@Autowired可以設置required=false而@Inject并沒有這個屬性。

@Resource

@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 注入(屬性注入)

基于 setter 注入

基于 constructor 注入(構造器注入)

1. 基于 field 注入

所謂基于 field 注入,就是在bean的變量上使用注解進行依賴注入。本質上是通過反射的方式直接注入到 field。這是我平常開發中看的最多也是最熟悉的一種方式,同時,也正是 Spring 團隊所不推薦的方式。比如:

@Autowired private Svc svc;

2. 基于 setter 方法注入

通過對應變量的setXXX()方法以及在方法上面使用注解,來完成依賴注入。比如:

private Helper helper; @Autowired public void setHelper(Helper helper) { this.helper = helper; }

?“注:在 Spring 4.3 及以后的版本中,setter 上面的 @Autowired 注解是可以不寫的?!?/p>

?3. 基于 constructor 注入

將各個必需的依賴全部放在帶有注解構造方法的參數中,并在構造方法中完成對應變量的初始化,這種方式,就是基于構造方法的注入。比如:

private final Svc svc; @Autowired public HelpService(@Qualifier(“svcB”) Svc svc) { this.svc = svc; }

?“在 Spring 4.3 及以后的版本中,如果這個類只有一個構造方法,那么這個構造方法上面也可以不寫 @Autowired 注解?!?/p>

?基于 field 注入的好處正如你所見,這種方式非常的簡潔,代碼看起來很簡單,通俗易懂。你的類可以專注于業務而不被依賴注入所污染。你只需要把@Autowired扔到變量之上就好了,不需要特殊的構造器或者set方法,依賴注入容器會提供你所需的依賴。

基于 field 注入的壞處?“成也蕭何敗也蕭何”?

基于 field 注入雖然簡單,但是卻會引發很多的問題。這些問題在我平常開發閱讀項目代碼的時候就經常遇見。

容易違背了單一職責原則 使用這種基于 field 注入的方式,添加依賴是很簡單的,就算你的類中有十幾個依賴你可能都覺得沒有什么問題,普通的開發者很可能會無意識地給一個類添加很多的依賴。

但是當使用構造器方式注入,到了某個特定的點,構造器中的參數變得太多以至于很明顯地發現 something is wrong。擁有太多的依賴通常意味著你的類要承擔更多的責任,明顯違背了單一職責原則(SRP:Single responsibility principle)。?“這個問題在我司的項目代碼真的很常見。”?

依賴注入與容器本身耦合依賴注入框架的核心思想之一就是受容器管理的類不應該去依賴容器所使用的依賴。換句話說,這個類應該是一個簡單的 POJO(Plain Ordinary Java Object)能夠被單獨實例化并且你也能為它提供它所需的依賴。這個問題具體可以表現在:

你的類不能繞過反射(例如單元測試的時候)進行實例化,必須通過依賴容器才能實例化,這更像是集成測試

你的類和依賴容器強耦合,不能在容器外使用

不能使用屬性注入的方式構建不可變對象(final 修飾的變量)

Spring 開發團隊的建議?“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 的依賴注入有更深的理解。

責任編輯:haq

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 開發
    +關注

    關注

    0

    文章

    378

    瀏覽量

    42144
  • spring
    +關注

    關注

    0

    文章

    341

    瀏覽量

    15935
  • 智能構造器
    +關注

    關注

    0

    文章

    2

    瀏覽量

    5661

原文標題:Spring官方為什么建議構造器注入?

文章出處:【微信號:harmonyos_developer,微信公眾號:harmonyos_developer】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    深入解析RK平臺編譯核心:build.sh的知識點、調試技巧與開發價值

    在瑞芯微(RK)Linux SDK 開發,build.sh是整個編譯構建系統的“入口中樞”—— 它統一管理環境配置、命令解析、模塊構建與日志輸出,幾乎所有芯片(如 RK3588、RV1126)的固件編譯、內核構建、根文件系統定制都依賴
    的頭像 發表于 02-03 16:02 ?1901次閱讀
    深入解析RK平臺編譯核心:build.sh的<b class='flag-5'>知識點</b>、調試技巧與<b class='flag-5'>開發</b>價值

    開發過程中如何利用CW32L083系列微控制器的官方固件庫進行程序編寫和調試?

    開發過程中,如何利用CW32L083系列微控制器的官方固件庫進行程序編寫和調試?
    發表于 12-15 07:23

    開發指南】全志系列核心板開發過程中的常見問題及排查策略

    在長期提供技術支持服務的過程中,飛凌嵌入式總結了用戶開發全志系列產品時常見的問題及排查方法。本文中,小編將為大家梳理這些經驗,助力開發者快速定位問題,提升開發效率。
    的頭像 發表于 10-15 08:04 ?6870次閱讀
    【<b class='flag-5'>開發</b>指南】全志系列核心板<b class='flag-5'>開發過程中</b>的常見問題及排查策略

    芯片研發過程中的兩種流片方式

    芯片在研發過程中一般包含4個階段:芯片設計、生產樣片、測試驗證和大規模量產。在完成芯片設計后,工程師們需要先拿到一些芯片樣片,用它們進行測試和驗證,來判斷新研發的芯片在功能和性能上是否符合設計要求
    的頭像 發表于 09-09 15:04 ?1931次閱讀
    芯片研<b class='flag-5'>發過程中</b>的兩種流片方式

    如何保障遠程運維過程中的數據安全和隱私?

    LZ-DZ100背面 在分布式光伏集群的遠程運維,數據安全和隱私保護面臨多重風險,包括 傳輸過程中的竊聽 / 篡改、未授權訪問控制指令、設備固件被惡意植入、敏感數據(如站點位置、運行參數)泄露 等
    的頭像 發表于 08-22 10:26 ?989次閱讀
    如何保障遠程運維<b class='flag-5'>過程中</b>的數據安全和隱私?

    使用非隔離電源的觸控項目,遇到CS注入電流10v 動態CS,在觸控掃描F上觸摸按不動,怎么解決?

    你好,在使用非隔離電源開發 觸控項目,在進行10V cs注入電流測試時,發現在觸控掃描頻的倍頻上觸摸無法按動的情況,例如觸控掃描頻2M,即在CS
    發表于 08-08 07:18

    半導體硅片生產過程中的常用摻雜技術

    在半導體硅片生產過程中,精確調控材料的電阻率是實現器件功能的關鍵,而原位摻雜、擴散和離子注入正是達成這一目標的核心技術手段。下面將從專業視角詳細解析這三種技術的工藝過程與本質區別。
    的頭像 發表于 07-02 10:17 ?2370次閱讀
    半導體硅片生產<b class='flag-5'>過程中</b>的常用摻雜技術

    【「Yocto項目實戰教程:高效定制嵌入式Linux系統」閱讀體驗】01初讀體驗

    書的心得體會,獲取閱讀重點等信息。 推薦序知識點 從推薦序,可以獲得以下知識點: 這本書的學習過程中可以實操,沒有硬件條件的可以使用qemu模擬,有硬件條件的可以使用樹莓派5或者im
    發表于 06-30 21:49

    HarmonyOS實戰: 城市選擇功能的快速實現

    最近在日常開發過程中,需要實現城市選擇功能,同時支持模糊搜索??此坪唵蔚墓δ軇邮謱崿F起來卻有很多難點。本篇文章詳細記錄開發過程中遇到的問題和對應的解決方法,希望能夠幫助你,建議贊收藏!
    的頭像 發表于 06-24 17:07 ?488次閱讀

    使用CY7C65213開發過程中,應該用哪個interface進行uart通信?

    在使用CY7C65213開發過程中,我想用CyUartRead讀數據,但是好像沒有接口的deviceType是CY_TYPE_UART,想請問我應該用哪個interface進行uart通信? 是否有相關指導文件,或描述符指導?
    發表于 06-03 07:04

    明遠智睿SSD2351開發板:語音機器人領域的變革力量

    源的開發資料為開發者提供了深入研究和定制語音機器人功能的基礎,開發者可以根據不同的應用需求,對語音識別算法、語音合成引擎等進行優化和改進。一對一的技術支持則能及時解決開發過程中遇到的難
    發表于 05-28 11:36

    電機選型計算公式與知識點匯總

    純分享帖,需要者可點擊附件獲取完整資料~~~*附件:電機選型計算公式與知識點匯總.pdf 【免責聲明】內容轉自今日電機,因轉載眾多,無法確認真正原始作者,故僅標明轉載來源。版權歸原出處所有,純分享帖,侵權請聯系刪除內容以保證您的權益。
    發表于 04-29 16:10

    產品PCBA藍牙模組加工過程中的靜電防護知識

    器件包裝管包裝元器件。 PCBA加工行業對靜電防護部分投入已久,國內外PCBA產品穩定性上的差異也有很大一部分體現在生產過程中的靜電防護。因此PCBA加工過程靜電防護十分重要。 更多關于藍牙模組相關
    發表于 04-17 12:03

    半導體制造過程中的三個主要階段

    前段工藝(Front-End)、中段工藝(Middle-End)和后段工藝(Back-End)是半導體制造過程中的三個主要階段,它們在制造過程中扮演著不同的角色。
    的頭像 發表于 03-28 09:47 ?7298次閱讀
    半導體制造<b class='flag-5'>過程中</b>的三個主要階段

    電氣工程師必知必會的100個電?知識點分享

    電??程師也都是從電?學徒??步?步積累成長起來的。積跬步?千?,匯細流成江海!朋友們,現在讓我們??個捷徑,花半個?時的時間來積累100個必知必會的電?知識點吧!
    的頭像 發表于 03-14 11:05 ?1849次閱讀