好的設計能減少大量的工作-實習2周有感

目前對一個大型的web業務系統進行修修補補，增加功能，完成工作之余，不得不對大量冗余的工作量表示抱怨。一個好的系統應該 對修改關閉，對擴展開放。

下面開始意識流。。。。

•  統一的命名規范與接口

        命名規范沒什么好說的，一個團隊不一定要找最好的規范，但是必須統一。        接口與敏捷開發有些許的沖突，互聯網的日新月異，敏捷的快速迭代，貌似不能再開發初期就把整個系統設計好。不過還是有很多的規范或者習慣在項目或者說全部開發初期約定好，比如方法名稱的命名方式，重載的命名方式，參數順序等等等等。 幾個簡單的例子。

• GetList的時候 返回值盡量用  IEnumable 而不是  List或者IList。
• 重載的時候差異的參數應該放后面等等。

 

•  （減少&整合） 函數參數  比如對查詢結果進行篩選，通過下面的方式 ，如果要增加一個篩選條件。。。太痛苦了

  public IEnumable<Model> GetList(
                int? cityID,
                DateTime? beginTime,
                DateTime? endTime){}

  不如下面這樣，這樣在以后的修改中不需要因為增加一個查詢參數對很多Service代碼進行修改。

  public Class QueryFiter
  {
      public int? CityID{get;set;}
      public DateTIme? BeginTIme{get;set;}
      public DateTIme? EndTIme{get;set;}
  }
  public IEnumable<Model> GetList(QueryFitter fiter){}

能通過其他方式獲取的參數就可以省略，比如 HttpContext.Current.

 

•  AOP，權限，日志：

目前的設計是將管理業務與權限管理（日志管理)完全結合在一起（操作前都需要判斷權限)，耦合度高,且引入大量冗余代碼，需要每個操作都進行判斷。 比如:

public class A
{ 
      public method()
      {
      //權限判斷邏輯
      //核心邏輯 
      //記錄日志
      }
 }

 而在一個系統中，類似的權限控制會很多，這些代碼就好像一顆顆毒瘤一般蔓延於系統中的各處，一旦需要擴展，冗余的工作量很大，而且很容易出現遺漏和bug。

我能想到的解決方案：

1. 利用AOP進行業務的橫向切入，把權限判斷邏輯和日志記錄邏輯完全獨立出來。（最好的辦法）。PostSharp  &   自己寫一個簡單的AOP框架。
2. 利用裝飾着模式，對於每個業務類進行包裝，不過會產生大量的類。不過可以通過泛型 特性Attribute和反射改善一些。
3. 使用MVC里的Fitter（如果使用mvc ）這樣應該也是AOP范疇吧

改善后的代碼應該是這樣的

public class Component:IComponent
{
      [RequireAdmin(Power=999)]
      [Log(lever=1)]
      public Method A(){  }
}

• 數據庫查詢

1.ORM

關於ORM，不能因為ORM而ORM。 如果業務太復雜，需要大量的多表查詢，各種jion, union,這時候就不要使用ORM。 為了實體映射，有時候在做多表查詢的時候可能需要會把所有的數據取出來，然后用相關的邏輯去拼接出需要的數據，導致數據庫查詢非常慢。 而且，對於敏捷開發，增加一個數據表字段應該很常見的需求，如果ORM，則需要修改多個地方。

2.延遲查詢&延遲加載：程序員都想偷懶，何況數據了。

3.能早篩選盡量早篩選，最還在select的時候就使用Where條件篩選掉。特別是多表查詢的時候。

• 緩存

應用緩存可以減少數據庫壓力，提供頁面速度。 非實時數據可以緩存，或者說可以緩存的大數據（查詢緩慢）都應該嘗試着緩存。

• AJAX

JS框架，不管是Jquery mootools 或者自用的框架，必須統一，而且存放的目錄和要取的文件名必須約定，調用方式也應該統一。返回的Json格式也要用統一的規范。

AJAX處理程序，如果是同一個業務，可以放在同一個ashx里處理。使用反射+xml+?工廠方法避免switch是一個很好的注意。或者使用反射實現客戶端調用服務端方法也是個不錯的主意。

AJAX必須有返回數據，客戶端必須在確認服務端返回成功的信息后才更新網頁，不能沒收到確認就先更改頁面。錯誤的提示要盡可能詳細與易懂，能幫助開發人員快速定位bug。

• 異常

        說說我的想法：異常處理，除非是可以容錯的錯誤，不如，在service層里不應該把異常Catch掉，即使Catch掉（比如記錄錯誤日志，數據庫回滾，也應該繼續throw出來，然后在展示層告訴用戶是什么出錯了，應該怎么處理等等。 前台獲取客戶端數據，少用Int.TryParse等方法屏蔽錯誤，而是應該把一系列的獲取放在一個try里，如果出錯要把這個錯誤包裝翻譯一下返回客戶端，。不應該出現任何莫名其妙無法判斷的錯誤。

硬編碼

系統中不應該出現任何的硬編碼，有含義的數字，比如表示權限的權限值，都應該用枚舉替代。

• SESSION & COOKIE & CACHE & VIEWSTATE

     

    到底是session還是cookie好這個沒必要討論。

    但是，在一個大型的系統中，我覺得（僅僅是我覺得），這部分細節應該被包裝，對程序員透明，使用統一的包裝類進行訪問，而不應該莫民奇妙的出現session或者cookie。

個人認為，VIEWSTATE這玩意，應該能不用就不用，直接在web.config里禁用掉。

 

• 配置文件

 項目較大，配置項必然多，這時候就非常必要進行拆分，.net的web.config本來就支持拆分為多個配置，不同目的的配置項應該按期分類放在多個config里，文件名必須有意義。

 

• 單元測試 & 短函數

有關單元測試，這沒什么好說的，不過，如果使用短函數，能把bug出現的情況完全控制到一目了然的情況，是否可以省略呢？

 

• 細節

系統的性能並不都是架構問題，還可能是細節問題。

     比如字符串到底是直接 + 呢 還是  String.Concat()   或者是 String.Format  還是  SringBulder  還是其他等等，都要考慮，盡量統一。

     GetList的時候 返回值盡量用  IEnumable 而不是  List或者IList。

    編碼問題  整個項目必須統一是UTF-8還是GB2312等等。

 

下面就是一些小問題了

 

• 服務器控件

我們用的項目是一個老項目webform修改的，用了大量的服務器控件，這無可后非，要徹底改掉成本太大。但是，服務器控件有局限性，如果這個服務器控件不能滿足要求的時候，不能簡單在aspx里添加處理邏輯或者把綁定的值傳回后台函數進行判斷，這時候可以使用自定義用戶控件去處理這樣的邏輯。

 

 

未完待續。。。。

 

 

 

 

 

 

 

 

文章來源：http://blog.xujif.com/archives/better-design-less-work/