Spring的@Autowire和@Resource註解使用方式推薦

序言

翻譯自field-injection-is-not-recommended，加入了本身的白話理解!

介紹

今天使用Idea寫代碼的時候，看到以前的項目中顯示有warning的提示，去看了下，是以下代碼?

@Autowire
private JdbcTemplate jdbcTemplate;
複製代碼

提示的警告信息

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".

這段是Spring工做組的建議，大體翻譯一下：
屬性字段注入的方式不推薦，檢查到的問題是：Spring團隊建議:"始終在bean中使用基於構造函數的依賴項注入， 始終對強制性依賴項使用斷言"
複製代碼

如圖

注入方式

雖然當前有關Spring Framework（5.0.3）的文檔僅定義了兩種主要的注入類型，但實際上有三種:

• 基於構造函數的依賴注入

  public class UserServiceImpl implents UserService{
      private UserDao userDao;
      
      @Autowire
      public UserServiceImpl(UserDao userDao){
          this.userDao = userDao;
      }
  }
  複製代碼

• 基於Setter的依賴注入

  public class UserServiceImpl implents UserService{
       private UserDao userDao;
       
       @Autowire
       public serUserDao(UserDao userDao){
           this.userDao = userDao;
       }
   }
  複製代碼

• 基於字段的依賴注入

  public class UserServiceImpl implents UserService{
       @Autowire
       private UserDao userDao;
   }
  複製代碼

基於字段的依賴注入方式會在Idea當中吃到黃牌警告，可是這種使用方式使用的也最普遍，由於簡潔方便.您甚至能夠在一些Spring指南中看到這種注入方法，儘管在文檔中不建議這樣作.(有點執法犯法的感受)

如圖

基於字段的依賴注入缺點

• 對於有final修飾的變量很差使   

  Spring的IOC對待屬性的注入使用的是set形式，可是final類型的變量在調用class的構造函數的這個過程中就得初始化完成，這個是基於字段的依賴注入作不到的地方．只能使用基於構造函數的依賴注入的方式

• 掩蓋單一職責的設計思想

  咱們都知道在OOP的設計當中有一個單一職責思想，若是你採用的是基於構造函數的依賴注入的方式來使用Spring的IOC的時候，當你注入的太多的時候，這個構造方法的參數就會很龐大，相似於下面.當你看到這個類的構造方法那麼多參數的時候，你天然而然的會想一下:這個類是否是違反了單一職責思想?.可是使用基於字段的依賴注入不會讓你察覺，你會很沉浸在@Autowire當中

  public class VerifyServiceImpl implents VerifyService{
      
    private AccountService accountService;
    private UserService userService;
    private IDService idService;
    private RoleService roleService;
    private PermissionService permissionService;
    private EnterpriseService enterpriseService;
    private EmployeeService employService;
    private TaskService taskService;
    private RedisService redisService;
    private MQService mqService;
  
    public SystemLogDto(AccountService accountService, 
                        UserService userService, 
                        IDService idService, 
                        RoleService roleService, 
                        PermissionService permissionService, 
                        EnterpriseService enterpriseService, 
                        EmployeeService employService, 
                        TaskService taskService, 
                        RedisService redisService, 
                        MQService mqService) {
        this.accountService = accountService;
        this.userService = userService;
        this.idService = idService;
        this.roleService = roleService;
        this.permissionService = permissionService;
        this.enterpriseService = enterpriseService;
        this.employService = employService;
        this.taskService = taskService;
        this.redisService = redisService;
        this.mqService = mqService;
    }
  }
  複製代碼

• 與Spring的IOC機制緊密耦合  

  當你使用基於字段的依賴注入方式的時候，確實能夠省略構造方法和setter這些個模板類型的方法，可是，你把控制權全給Spring的IOC了，別的類想從新設置下你的某個注入屬性，無法處理(固然反射能夠作到).自己Spring的目的就是解藕和依賴反轉，結果經過再次與類注入器（在本例中爲Spring）耦合，失去了經過自動裝配類字段而實現的對類的解耦，從而使類在Spring容器以外無效.  

• 隱藏依賴性

  當你使用Spring的IOC的時候，被注入的類應當使用一些public類型(構造方法，和setter類型方法)的方法來向外界表達:我須要什麼依賴.可是基於字段的依賴注入的方式，基本都是private形式的，private把屬性都給封印到class當中了.

• 沒法對注入的屬性進行安檢

  基於字段的依賴注入方式，你在程序啓動的時候沒法拿到這個類，只有在真正的業務使用的時候纔會拿到，通常狀況下，這個注入的都是非null的，萬一要是null怎麼辦，在業務處理的時候錯誤才爆出來，時間有點晚了，若是在啓動的時候就暴露出來，那麼bug就能夠很快獲得修復(固然你能夠加註解校驗).若是你想在屬性注入的時候，想根據這個注入的對象操做點東西，你沒法辦到．我碰到過的例子：一些配置信息啊，有些人老是會配錯誤，等到了本身測試業務階段才知道配錯了，例如線程初始個數不當心配置成了3000，機器真的是狂叫啊!這個時候就須要再某些Value注入的時候作一個檢測機制.

結論

經過上面，咱們能夠看到，基於字段的依賴注入方式有不少缺點,咱們應當避免使用基於字段的依賴注入.推薦的方法是使用基於構造函數和基於setter的依賴注入.對於必需的依賴項，建議使用基於構造函數的注入，以使它們成爲不可變的，並防止它們爲null。對於可選的依賴項，建議使用基於Setter的注入

後記

翻譯自field-injection-is-not-recommended，加入了本身的白話理解!