持續重構，其樂無窮。

一：發現問題

　　先來說如何重構業務層的try{}catch{}finally{}代碼塊，我看過很多代碼，異常處理這一塊大致分為兩種情況，一種是每個方法都大量的充斥著try{}catch{}finally{}，這種方式的編程已經考慮到了異常處理，還有一種就是沒有try{}catch{}finally{}的代碼，因為根本就沒有考慮代碼的異常處理。每當我看到這樣的代碼，我都很憂傷。從程序的健壯性來看第一種還是要比第二種情況好，至少在編程意識中，隨時想到了異常情況，有一種基本的編程思想。

　　比如：一個業務單據的多表插入，關聯修改，虛擬刪除等都是一些基本的操作，但是又是比較容易引起錯誤的操作，在這些方法上都會加上try{}catch{}finally{}對代碼進行有效的防錯處理。早期的代碼是這樣的。

public Boolean Save(AccountModel accountData) {Boolean result = false;try{//TODO ...result = true;}catch{}finally{ }return result; }public Boolean Edit(AccountModel accountData) {Boolean result = false;try{//TODO ...result = true;}catch{}finally{}return result; }public Boolean VirDelete(AccountModel accountData) {Boolean result = false;try{//TODO ...result = true;}catch{}finally{}return result; }

僅僅定義了添加，修改，刪除幾個空方法，就寫了三四十行代碼，如果業務稍微復雜些，異常處理的代碼很快就會突破百行大關。雖然復制，粘貼try{}catch{}finally{}很好使，但是業務邏輯代碼大量充斥著這樣的try{}catch{}finally{}代碼，確實顯得做事不夠利落。

二：解決問題

　　那怎樣來解決這件棘手的事呢，首先定義一個公用的try{}catch{}finally{}，如下如示：

public class Process {public static bool Execute(Action action){try{action.Invoke();return true;}catch (Exception ex){//1，異常隱藏//2，異常替換//3，異常封裝//寫日志return false;}finally{}} }

上邊的代碼定義了公用的try{}catch{}finally{}，最關鍵是怎么運用起來，如下代碼：

protected void Page_Load(object sender, EventArgs e) {AccountModel accountData = new AccountModel(); //準備傳入的參數Boolean result = false; //接收返回的值Process.Execute(() => result = Save(accountData)); //執行方法 }public Boolean Save(AccountModel accountData) {Boolean result = false;//TODO ...result = true;return result; }public Boolean Edit(AccountModel accountData) {Boolean result = false;//TODO ...result = true;return result; }public Boolean VirDelete(AccountModel accountData) {Boolean result = false;//TODO ...result = true;return result; }

這樣的精簡過的代碼，是不是感覺心情很舒暢。

三：提升與擴展

?　　對于知足者常樂的人來說，到第二個步驟就可以洗洗睡了。但是對于精益求精的人來說，問題仍然沒有完。我們來說一個應用場景，在WCF中的應用，我們知道WCF服務端的異常，不經過<serviceDebug includeExceptionDetailInFaults="true"/>的設置，服務端的異常是無法拋到客戶端的。但是在正式環境中，不可能對進行serviceDebug的配置。正確的處理是在服務端對異常進行隱藏，替換，或者封裝。

　　比如我們在服務端捕獲了一個已知異常，但是這個異常會暴露一些敏感的信息，所以我們對異常進行替換，拋出新的異常后，我們還要把這個異常怎樣傳輸給客戶端。首先們要明確WCF中的一些基本常識，就是WCF中的數據傳遞要遵循WCF的數據契約，服務端拋到客戶端的異常（異常其實也是數據），所以必須要給異常定義異常契約。

[DataContract(Name = "WCFException")]public class WCFException{[DataMember(Name = "Type")]public String Type { get; set; }[DataMember(Name = "StackTrace")]public String StackTrace { get; set; }[DataMember(Name = "Message")]public String Message { get; set; }}

然后處理異常的公共方法改寫為：

public static bool Execute(Action action) {try{action.Invoke();return true;}catch (Exception ex){//1，異常隱藏//2，異常替換//3，異常封裝//寫日志WCFException exception = new WCFException{Type = "Error",StackTrace = ex.StackTrace,Message = ex.Message};throw new FaultException<WCFException>(exception, new FaultReason("服務端異常:" + ex.Message), new FaultCode(ex.TargetSite.Name));}finally{} }

這樣在服務端拋出的異常，就能在客戶端捕捉到。現在是不是感覺自己又提升了一些，想成為編程高手是指日可待了。

四：舉一反三

　　異常的處理也不過如此，那是不是應該舉一反三，看看事務的處理應該怎么辦？比如現在大量的訪求都用到了事務，如下代碼：

public Boolean Save(AccountModel accountData) {OracleConnection conn = new OracleConnection("連接字符串");IDbTransaction trans = conn.BeginTransaction();Boolean result = false;try{//TODO ... trans.Commit();result = true;}catch{trans.Rollback();}finally{}return result; }

特別是 trans.Commit(); ?trans.Rollback(); 這樣的代碼出現在每個與事務相關的方法中， 讓我感覺到代碼的臃腫，以及隱陷約約的失望。
經過我幾天的翻閱資料終于實現了事務的公用訪求提取。使用方法如下代碼所示：

[TransactionAttribute] [ExceptionAttribute] public bool Save(DataContext dContext, Dictionary<string, string> dtoPara) {Boolean returnVal = true;//TODO ...return returnVal; }

就是在一個方法上加[TransactionAttribute]就表示這個方法寫在了事務中，反之，不在事務中，加[ExceptionAttribute]就表示這個方法作了異常處理，反之，不作異常處理。通過反射或者AOP都能實現Attribute編程的效果。最后，還有什么疑惑，可以在評論中給我留言，當然別忘記了下方的【推薦】。

from: http://www.cnblogs.com/xcj26/p/3442089.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的精简自己20%的代码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。