服務層的必要性

捕獲異常

調試某個項目，搭建好環境，打開首頁，而後是一個大黃頁（500），錯誤信息是NullReferenceException。而後Debug了一下代碼，原來數據庫鏈接字符串錯誤，做者在DBHelper中捕獲了異常，這樣DBHelper裏的方法的返回值就是一個null。對於這樣的try...catch...我也是醉了，我表達的意思在這種狀況下，不捕獲異常要比捕獲異常好不少。捕獲了異常引起了其餘的錯誤，更浪費開發人員的時間。我敢確定我絕對不是第一個被這樣的代碼坑的，也不會是最後一個。
既然在DBHelper捕獲異常不正確，那麼應該在哪裏捕獲異常呢？個人建議是統一捕獲，數據訪問層不適合捕獲異常，由於數據訪問層的定位是專一於數據訪問，業務邏輯層亦不適合捕獲異常，由於業務邏輯層專一於領域邏輯和應用邏輯的處理。數據訪問層和業務邏輯層只要專一於可以正確的執行就好。 這個時候就須要在業務邏輯層之上再搭建一層，這層就是服務層，如圖

(圖片來源 http://www.cnblogs.com/DotCpp/p/4291113.html)

將捕獲異常和處理錯誤的代碼放在服務層中。

並非全部拋出的異常都在service中去捕獲，主要仍是看異常場景，

1. 異常已經形成了當前執行流程的阻斷就須要在service層捕獲。
2. 異常引起流程控制，並不須要阻斷當前流程。舉個例子先請求A，若A異常了，則在請求B。這樣的狀況就能夠在當前代碼捕獲異常。

.NET異常模型，對於開發者是友好的，可是對於用戶來講並不友好，好比出現了異常，就展示一個大黃頁，用戶會不知所措。用戶但願看到的是友好的提示信息，而不是錯誤編碼和堆棧信息。這個時候咱們就須要對錯誤模型轉換，由Exception轉化爲錯誤編碼。在UI層經過錯誤編碼以合理的方式將信息展示給用戶。

業務邏輯協調

對於交易這種複雜的業務流程來講，完成這樣的一個流程須要若干個子業務流程協同完成。舉個例子，假設最初買一件衣服須要兩個流程

1. 將錢充值帳戶，寫充值記錄；
2. 使用帳號購買衣服，寫消費記錄；

這兩個流程是分別進行的，即向買件衣服以前必須向帳號內充值。有一天，PM意識到這個事情對用戶太不友好了，因此就須要這兩個流程一鼓作氣，可是想一鼓作氣須要解決一系列的問題，如充值流程不成功、衣服下架，須要退款。這就出現了不少協調這兩個流程的業務邏輯，甚至會衍生出新的業務邏輯好比退款。那麼協調這部分業務邏輯的代碼應該放哪兒？ 放UI層不合理的，由於UI層主要負責表現業務邏輯處理，用戶參數校驗等。因此咱們須要新添加一個層，這個層就是業務外觀層，來作業務流程協調。