今天跟同事討論了一下在Spring Boot中,是使用@Configuration和@Bean的組合來創建Bean還是直接使用@Service等註解放在類上的方式。筆者傾向於使用第一種,即@Configuration和@Bean的組合。
先來看一個例子,目標是創建SearchService的一個Bean。
直接使用@Service的方式:
// SearchService.javapackage li.koly.search;import java.util.List;public interface SearchService { List<Object> search(String q);}// ElasticSearchServiceImpl.javapackage li.koly.search;import org.springframework.stereotype.Service;import java.util.Arrays;import java.util.List;@ServiceComponentpublic class ElasticSearchServiceImpl implements SearchService { @Override public List<Object> search(String q) { return Arrays.asList("hello", q); }}// Application.javapackage li.koly.search;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RestController;import java.util.List;@SpringBootApplication@RestControllerpublic class Application { @Autowired private SearchService searchService; @GetMapping("/search") public List<Object> hello(String q) { return searchService.search(q); } public static void main(String[] args) { SpringApplication.run(Application.class, args); }}啟動Application,瀏覽器訪問: http://localhost:8081/search?q=koly ,頁面顯示:["hello","koly"]
使用@Configuration和@Bean的方式:
// ElasticSearchServiceImpl.javapackage li.koly.search;import java.util.Arrays;import java.util.List;public class ElasticSearchServiceImpl implements SearchService { @Override public List<Object> search(String q) { return Arrays.asList("hello", q); }}// AppConfig.javapackage li.koly.search;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;@Configurationpublic class AppConfig { @Bean public SearchService searchService() { return new ElasticSearchServiceImpl(); }}相比直接使用@Service的代碼,多了一個AppConfig類,移除了放在ElasticSearchServiceImpl上面的@Service註解。一眼看去,代碼和類還多了。那麼使用後者的好處是什麼呢?
筆者認為,好處有:
關注點分離
使用@Configuration和@Bean的方式,Bean的創建全部放到了一個地方,接口及其實現完全跟Bean創建沒有了關係。
如果Bean的創建需要改動,那麼只需要查看並修改對應的Configuration類就行,並不需要去到對應的Java Bean進行改動。比如可能有時候Bean創建需要同@Scope或者@Profile配合,此時只需要修改Configuration類就行了。
單一職責
@service註解本身就承擔了兩個職責:
一是Bean的創建;
二是將一個類標識為一個服務。
Indicates that an annotated class is a "Service", originally defined by Domain-Driven
Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."
上面是Spring對於@Service註解的說明。也就是說@Service實際上表示了DDD中的無狀態的,獨立的,以接口的形式提供的一個操作。
而採用@Bean和@Configuration配合的方式,Bean的創建交給了單獨的類,而Service的標識交給了Java中的Interface以及類的名字。這點在Spring Data也有所體現,比如Repository就是通過名字來標識,如CrudRepository。因此Service也通過名字來體現。具體層次定義,通過名字而不依賴Spring提供的註解,便於根據項目提供更多的層次,比如Mapper層,Validator層等。
另為,本身Bean和Service就是兩個維度的概念。一個關於具體實現,另一個關於DDD中的概念。
更靈活
使用@Bean的方式,能夠創建庫裡面的類的實例。如果使用@Service的方式,沒辦法在庫裡面對應的類上添加@Service註解。
least knowledge(最小知識原則)
最小知識原則的意思是:
完成功能需要的技術或者知識越少越好,這樣才能保證項目簡單,同時降低項目的學習難度。
由於使用@Service無法創建類庫中的類的實例,因此在遇到類似需求時,不得不使用@Configuration和@Bean的形式。此時,整個項目中就同時存在@Service,@Configuration和@Bean等註解,而這些註解所做的事情都是一樣的,即Bean的創建。
使用@Service,很有可能出現@Service,@Component,@Configuration和@Bean同時存在的情況。
而使用@Configuration和@Bean則完全可以不使用@Service和@Component,符合最小知識原則。
最後,順便說一句,之前Spring的Bean創建是在xml裡面,後面使用了Java做配置。不使用xml的主要原因是xml不夠簡潔,且沒有編譯時檢查等功能,而不是說需要將Bean的創建分散到各個類裡。
綜上,筆者更傾向與使用@Configuration和@Bean的方式。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持武林網。