在Spring框架中最常見的幾個注解

@Controller, @Service, @Component, @Repository

其中@Component是一種通用名稱，泛指任意可以通過Spring來管理的組件，@Controller, @Service, @Repository則是一種特定的組件，通常用來表示某種特定場合下的組件，比如@Repository用來表示倉庫（數(shù)據(jù)層，DAO），并且Spring 框架會根據(jù)這種應(yīng)用場景做些定制，比如@Repository同時具備了自動化的異常轉(zhuǎn)換。類似的， @Service則用來表示服務(wù)層相關(guān)的類， @Controller則用來表示展示層（presentation）的類。

[[214241]]

那Service是什么呢？

Service 表示了在軟件分層設(shè)計(jì)中的Service層，用來連結(jié)數(shù)據(jù)層（DAO）和展示層（Presentation）。

為什么要在DAO層上加一層Service呢？

在某些簡單的應(yīng)用中，DAO層的功能和Service的功能很接近，甚至初學(xué)者會覺得Service層做的事情和DAO層都一樣，那為啥還要將Service層單獨(dú)拿出來做一遍呢？而且，很多場景下，Service層和DAO層同時存在，往往會增加代碼復(fù)雜度，編碼工作量，寫的不好甚至?xí)斐苫煜?/p>

通常來說，DAO層應(yīng)盡力保持簡單，其功能僅僅是提供了數(shù)據(jù)庫的連接，以及最簡單的增刪改查（Crud），有時還需要做些抽象，以此來連接使用不同技術(shù)的數(shù)據(jù)庫。除此之外，任何業(yè)務(wù)相關(guān)的操作都應(yīng)該放到Service層，即Service層用來編寫業(yè)務(wù)邏輯，即操作從DAO層讀取的數(shù)據(jù)，或者將處理好的數(shù)據(jù)給DAO層，當(dāng)使用Domain Driven Design時， 這兩個類通常會放到同一個Domain（包）中，即便在簡單的應(yīng)用中，他們的代碼可能極其類似，但是仍應(yīng)該分別對待。而不是跳過service層（service）直接去使用DAO層（repository）來放業(yè)務(wù)邏輯數(shù)據(jù)。

這樣帶來的好處帶來更好的模塊化結(jié)構(gòu)，有便于后期的擴(kuò)展和維護(hù)，比如更換數(shù)據(jù)庫實(shí)現(xiàn)時，我們僅僅需要處理DAO層的內(nèi)容就好了。并且，當(dāng)業(yè)務(wù)邏輯比較復(fù)雜的時候，比如有很多報告要出的時候，Service層就提供了一個很好的空間來實(shí)現(xiàn)這些代碼。

其次，在web應(yīng)用開發(fā)中，使用Service層可以將web類的活動限制在controller中，這樣可以獨(dú)立的測試service層

另外，還有一種情況，就是當(dāng)應(yīng)用極其復(fù)雜，需要同時使用多種數(shù)據(jù)庫時，將從DAO中獲取數(shù)據(jù)的動作放到一起可以減少數(shù)據(jù)庫的操作，并且可以保證數(shù)據(jù)的一致性。同時Service可以嵌套，因此如果需要使用不同的數(shù)據(jù)庫時，可以在service中指定。

在Service中也可以放一些通知類的操作，比如發(fā)送郵件等，這樣也可以保持controller的整潔。

還有一個潛在的好處是安全性，當(dāng)使用service層包裹DAO層后，數(shù)據(jù)庫的鏈接是被service層保護(hù)起來的，這樣如果客戶端被某種情況攻陷，其只能使用service層提供的有限數(shù)據(jù)，而無法直接攻擊數(shù)據(jù)庫

另外，在Spring 框架中，security也是在Service層實(shí)現(xiàn)的。根據(jù)上面的邏輯，我們在實(shí)際開發(fā)中，應(yīng)該不去實(shí)現(xiàn)自己的DAO層，而是使用Spring Data JPA，因?yàn)镾pring Data JPA已經(jīng)實(shí)現(xiàn)了DAO層。

這種寫法常見的問題有啥？

最常見的寫法（或者是錯誤的寫法）有以下幾種

1、面向領(lǐng)域的模型對象僅僅用來存儲應(yīng)用中的數(shù)據(jù)，換句話說，是不太符合domain model 設(shè)計(jì)的

2、處理模型數(shù)據(jù)的業(yè)務(wù)邏輯分散在service層

3、每個entity都有對應(yīng)的service類

這樣寫的原因很大程度來源于上面的分層理論，我們確實(shí)將應(yīng)用分成了展示層（web layer），服務(wù)層（service layer），數(shù)據(jù)層（repository/dao），但是實(shí)際后果卻是一個極其龐大的service層，這種寫法可以算是一個面向過程開發(fā)的代碼（procedural code）， 而不是面向?qū)ο箝_發(fā)。好處是簡單，當(dāng)業(yè)務(wù)不復(fù)雜時，確實(shí)沒有必要使用一個龐大的面向?qū)ο箝_發(fā)框架（domain driven design）。

一個責(zé)任并不明確的service層主要有以下問題

1、業(yè)務(wù)邏輯分散在service層中，當(dāng)我們需要確認(rèn)或者檢查某個業(yè)務(wù)邏輯時，可能要在多個service類中尋找，也許并不那么容易，另外如果同樣的業(yè)務(wù)邏輯在多個service類中用到時，那么可能會存在大量的重復(fù)代碼，這種重復(fù)代碼對于維護(hù)人員來說就是惡魔。

2、在service層中，每個entity都有對應(yīng)的service類時，service層會有過多的依賴，甚至是循環(huán)依賴關(guān)系，而不是由松散耦合的service類構(gòu)成service層，理想中的service層應(yīng)該是由具有單一責(zé)任的service類構(gòu)成，并且這些service類具有松耦合關(guān)系，如果不是這樣的service層，將難以理解，維護(hù)和重用。

主要的解決方法是

1、將與entity相關(guān)的業(yè)務(wù)邏輯統(tǒng)一放到領(lǐng)域模型對象相關(guān)的類中，即所謂的domain service中。這樣做的好處時，傳統(tǒng)概念中的service層僅僅處理應(yīng)用相關(guān)的業(yè)務(wù)邏輯，即作為Application Service。 然后domain service中處理domain 內(nèi)的業(yè)務(wù)邏輯。業(yè)務(wù)邏輯將按照domain和application的方式分開，容易定位和維護(hù)。傳統(tǒng)意義上的applicationservice層將變得整潔。

2、在domain service中我們將按照entity來編寫對應(yīng)的service，這些都是特定的service，很小，僅僅面對很專一的功能。舉例來說，如果應(yīng)用中的某個service提供person類的crud， 同時還提供用戶帳號的操作，那么我們應(yīng)該將person的crud單獨(dú)放到一個service中，然后將用戶帳號相關(guān)的操作放到另一個service中。

所有這些分層方式都是為了解決應(yīng)用從小項(xiàng)目成長為大項(xiàng)目時可能遇到的隱患，代價是在項(xiàng)目還小時，增加了項(xiàng)目的復(fù)雜度，往往一句代碼就能搞定的事情，卻要拆到三個類中去。但是太多的實(shí)際例子表明，如果沒有好的架構(gòu)，當(dāng)小項(xiàng)目膨脹到一定程度時，往往是無法維護(hù)的，只能全部推倒重寫。

在Domain Driven Design中如何區(qū)分各種Service？

在DDD中，service有三種類型

Domain Service

Domain Service: 用于放置領(lǐng)域?qū)ο笙嚓P(guān)的業(yè)務(wù)邏輯，這些業(yè)務(wù)邏輯通常并不適合放到entity中，也不是常見到的CRUD(這些應(yīng)該放到Repository)， 將Domain Service 和Domain Objects放到一起是合理的，它們都是關(guān)注于domain相關(guān)的業(yè)務(wù)邏輯。在Domain Service中可以使用注入repository的方式來使用entity對應(yīng)的repository。

舉一個例子：

一個圖書館有三個entity：Book， Client，Inventory， 當(dāng)把一本書借給一個客戶時，就對應(yīng)了一個Domain Service。在一個例子，在Eric Evans的《Domain Driven Design》書中，轉(zhuǎn)賬服務(wù)（FundsTransferService）也是一種domain service，它涉及到帳號BankAccount，但是并不適合放到BankAccount中。

Application Service

Application Service: 用于為應(yīng)用外的client或consumer提供應(yīng)用級別的服務(wù)，比如一個外部客戶端（程序）需要使用某個entity的CRUD時，這些服務(wù)程序放到Application Service。

Application Service通常會使用Domain Service和repository來處理外部的請求。常見的場景是，從repository中拿到一些domain objects， 然后執(zhí)行某些操作，在將其放回repository（或者不放）， Application Service對應(yīng)著大部分用戶使用場景，在寫一個應(yīng)用時，可以先從Application service寫起，這樣可以很好界定應(yīng)用的功能和范圍。repository雖然可以在某些場景下注入到domain service中，但是更常見的是注入到applicatinoservice中。

Infrastructure service

還有一種Infrastructure service：用于抽象一些技術(shù)問題，比如消息隊(duì)列，郵件服務(wù)

具體例子spring-petclinic