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

@Controller, @Service, @Component, @Repository

其中@Component是一種通用名稱，泛指任意可以通過Spring來管理的元件，@Controller, @Service, @Repository則是一種特定的元件，通常用來表示某種特定場合下的元件，比如@Repository用來表示倉庫（資料層，DAO），並且Spring 框架會根據這種應用場景做些定製，比如@Repository同時具備了自動化的異常轉換。類似的， @Service則用來表示服務層相關的類， @Controller則用來表示展示層（presentation）的類。

那Service是什麼呢？

Service 表示了在軟體分層設計中的Service層，用來連結資料層（DAO）和展示層（Presentation）。

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

在某些簡單的應用中，DAO層的功能和Service的功能很接近，甚至初學者會覺得Service層做的事情和DAO層都一樣，那為啥還要將Service層單獨拿出來做一遍呢？而且，很多場景下，Service層和DAO層同時存在，往往會增加程式碼複雜度，編碼工作量，寫的不好甚至會造成混淆。

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

這樣帶來的好處帶來更好的模組化結構，有便於後期的擴充套件和維護，比如更換資料庫實現時，我們僅僅需要處理DAO層的內容就好了。並且，當業務邏輯比較複雜的時候，比如有很多報告要出的時候，Service層就提供了一個很好的空間來實現這些程式碼。

其次，在web應用開發中，使用Service層可以將web類的活動限制在controller中，這樣可以獨立的測試service層

另外，還有一種情況，就是當應用極其複雜，需要同時使用多種資料庫時，將從DAO中獲取資料的動作放到一起可以減少資料庫的操作，並且可以保證資料的一致性。同時Service可以巢狀，因此如果需要使用不同的資料庫時，可以在service中指定。

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

還有一個潛在的好處是安全性，當使用service層包裹DAO層後，資料庫的連結是被service層保護起來的，這樣如果客戶端被某種情況攻陷，其只能使用service層提供的有限資料，而無法直接攻擊資料庫

另外，在Spring 框架中，security也是在Service層實現的。根據上面的邏輯，我們在實際開發中，應該不去實現自己的DAO層，而是使用Spring Data JPA，因為Spring Data JPA已經實現了DAO層。

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

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

1、面向領域的模型物件僅僅用來儲存應用中的資料，換句話說，是不太符合domain model 設計的

2、處理模型資料的業務邏輯分散在service層

3、每個entity都有對應的service類

這樣寫的原因很大程度來源於上面的分層理論，我們確實將應用分成了展示層（web layer），服務層（service layer），資料層（repository/dao），但是實際後果卻是一個極其龐大的service層，這種寫法可以算是一個面向過程開發的程式碼（procedural code）， 而不是面向物件開發。好處是簡單，當業務不復雜時，確實沒有必要使用一個龐大的面向物件開發框架（domain driven design）。

一個責任並不明確的service層主要有以下問題

1、業務邏輯分散在service層中，當我們需要確認或者檢查某個業務邏輯時，可能要在多個service類中尋找，也許並不那麼容易，另外如果同樣的業務邏輯在多個service類中用到時，那麼可能會存在大量的重複程式碼，這種重複程式碼對於維護人員來說就是惡魔。

2、在service層中，每個entity都有對應的service類時，service層會有過多的依賴，甚至是迴圈依賴關係，而不是由鬆散耦合的service類構成service層，理想中的service層應該是由具有單一責任的service類構成，並且這些service類具有鬆耦合關係，如果不是這樣的service層，將難以理解，維護和重用。

主要的解決方法是

1、將與entity相關的業務邏輯統一放到領域模型物件相關的類中，即所謂的domain service中。這樣做的好處時，傳統概念中的service層僅僅處理應用相關的業務邏輯，即作為Application Service。 然後domain service中處理domain 內的業務邏輯。業務邏輯將按照domain和application的方式分開，容易定位和維護。傳統意義上的applicationservice層將變得整潔。

2、在domain service中我們將按照entity來編寫對應的service，這些都是特定的service，很小，僅僅面對很專一的功能。舉例來說，如果應用中的某個service提供person類的crud， 同時還提供使用者帳號的操作，那麼我們應該將person的crud單獨放到一個service中，然後將使用者帳號相關的操作放到另一個service中。

所有這些分層方式都是為了解決應用從小專案成長為大專案時可能遇到的隱患，代價是在專案還小時，增加了專案的複雜度，往往一句程式碼就能搞定的事情，卻要拆到三個類中去。但是太多的實際例子表明，如果沒有好的架構，當小專案膨脹到一定程度時，往往是無法維護的，只能全部推倒重寫。

在Domain Driven Design中如何區分各種Service？

在DDD中，service有三種類型

Domain Service

Domain Service: 用於放置領域物件相關的業務邏輯，這些業務邏輯通常並不適合放到entity中，也不是常見到的CRUD(這些應該放到Repository)， 將Domain Service 和Domain Objects放到一起是合理的，它們都是關注於domain相關的業務邏輯。在Domain Service中可以使用注入repository的方式來使用entity對應的repository。

舉一個例子：

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

Application Service

Application Service: 用於為應用外的client或consumer提供應用級別的服務，比如一個外部客戶端（程式）需要使用某個entity的CRUD時，這些服務程式放到Application Service。

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

Infrastructure service

還有一種Infrastructure service：用於抽象一些技術問題，比如訊息佇列，郵件服務

具體例子spring-petclinic