controller和service層的一些見解
阿新 • • 發佈：2019-02-09
接觸java EE開發一年不到，剛開始接觸時用就用到spring MVC，因為當時公司業務比較簡單，所以service層和dao層實際上是一樣的，業務邏輯全部放在了controller層來做；當時覺得很納悶，service層感覺是多餘的，根本用不到；
最近接觸的專案，架構師設計的框架，直接根據模型設計dao層介面和service介面，程式碼寫了不少，突然發現這麼定義介面很多功能是沒法實現的。於是回頭重新思考了spring MVC模型，剛才看了篇非常不錯的部落格，感覺作者能把這個問題解釋清楚了。
還是從MVC三層模型開始，這三層模型的設計之初，就是為了將業務層（controller）、檢視層（view）以及模型層（modal）區分開來。需要注意的是，這裡並沒有資料庫這個概念，所以模型層會有一些冗雜，兩個表的聯合查詢出來的資料，會被封裝成一個模型交給控制層；同樣的，控制層因為沒有服務的概念，如果專案比較大，也會變的有些冗餘。
基於controller和modal層並沒有很好的實現模組化，因此，我們將modal層去掉，改為更加原子化的dao層；同時，將controller層的業務邏輯，劃分成多個服務。每個服務可以組合使用dao層資料，組裝成一個服務，比如使用者的註冊服務；而controller層，呼叫多個service服務完成url請求。
簡單來說，增加service層，替換modal層，第一是細化了資料模型，使得我們在改動某張表時，只需要改動dao層實現即可，最大化的減少了程式碼的改動成本；當然，更多的情況是service服務和controller可能都需要更改； service層將controller的邏輯分類，保證了controller的邏輯更加清晰。
舉個生活中的例子，使用者預約某個酒店的客房，這是酒店首先會呼叫驗證服務對使用者提供的資訊進行驗證，之後呼叫預約服務進行預約，如果預約失敗，酒店可能會把客戶的預約資訊提交給另外一家酒店請求它們的預約服務，然後將結果返回給客戶；
對於服務層來說，需要判斷酒店是否有空餘客房，之後修改客房資訊，同時將客房和使用者資訊存入臨時表。這裡至少需要兩種不同的dao層服務實現service。
所以整體上來看，controllrt->service->dao至少是一對一，更多的情況下是一對多。這也就是service層存在的意義了。
最近接觸的專案，架構師設計的框架，直接根據模型設計dao層介面和service介面，程式碼寫了不少，突然發現這麼定義介面很多功能是沒法實現的。於是回頭重新思考了spring MVC模型，剛才看了篇非常不錯的部落格，感覺作者能把這個問題解釋清楚了。
還是從MVC三層模型開始，這三層模型的設計之初，就是為了將業務層（controller）、檢視層（view）以及模型層（modal）區分開來。需要注意的是，這裡並沒有資料庫這個概念，所以模型層會有一些冗雜，兩個表的聯合查詢出來的資料，會被封裝成一個模型交給控制層；同樣的，控制層因為沒有服務的概念，如果專案比較大，也會變的有些冗餘。
基於controller和modal層並沒有很好的實現模組化，因此，我們將modal層去掉，改為更加原子化的dao層；同時，將controller層的業務邏輯，劃分成多個服務。每個服務可以組合使用dao層資料，組裝成一個服務，比如使用者的註冊服務；而controller層，呼叫多個service服務完成url請求。
簡單來說，增加service層，替換modal層，第一是細化了資料模型，使得我們在改動某張表時，只需要改動dao層實現即可，最大化的減少了程式碼的改動成本；當然，更多的情況是service服務和controller可能都需要更改； service層將controller的邏輯分類，保證了controller的邏輯更加清晰。
舉個生活中的例子，使用者預約某個酒店的客房，這是酒店首先會呼叫驗證服務對使用者提供的資訊進行驗證，之後呼叫預約服務進行預約，如果預約失敗，酒店可能會把客戶的預約資訊提交給另外一家酒店請求它們的預約服務，然後將結果返回給客戶；
對於服務層來說，需要判斷酒店是否有空餘客房，之後修改客房資訊，同時將客房和使用者資訊存入臨時表。這裡至少需要兩種不同的dao層服務實現service。
所以整體上來看，controllrt->service->dao至少是一對一，更多的情況下是一對多。這也就是service層存在的意義了。