上一篇文章引來不少非議，筆者並非對EF有看法，而是針對不同的業務場景和框架背景，挑選不同的方案。每個方案都有其優勢劣勢，挑選最快速，最簡單的方案，是筆者的初衷。
看評論也是學習的過程，然而有些只做評價，卻不道明原委的評論，也確實讓筆者感受到了些許來自世界的惡意^_^
開個玩笑，下面進入正題，之前系統的支付部分只需要支持支付寶和財付通，且支付代碼是寫在一個頁面文件里的，也就是說，這個頁面文件包含了支付寶和財付通的支付請求、支付同步回調和異步回調。且不說代碼混亂可讀性差，其可擴展性也實在不敢恭維。其功能像這樣：
可將來需要支持其他支付平台呢，類似於快錢等支付平台，我們預期的是這樣甚至更多：
難道這些將來亟待擴展的功能還一一寫在頁面里嗎？當然不能。在擴展支付功能之前，必須對原來的代碼做重構。
重構前我們需要對目前的支付做分析：支付需要哪些方法？哪些是公共的？經過總結，我們發現支付寶和財付通支付最主要的就是這三個方法：
1.提交支付請求
2.支付同步回調（重定向）
3.異步回調
當然，有些支付平台可能有不同，比如支付寶的退款接口，是沒有同步回調的。如果有更多的場景，我們可以擴展接口。
我們定義了這樣一個接口類：
public interface IPayment { /// <summary> /// 支付 /// </summary> void GoToPay(PaymentParameter parameters); /// <summary> /// 支付同步回調 /// </summary> void PayReturn(); /// <summary> /// 支付異步回調 /// </summary> void PayNotify(); }
接下來構建基礎類，類名為PaymentBase，讓它繼承我們的接口類。基礎類中，我們定義各種平台支付所需要調用的公共方法，聲明支付所必需的對象，代碼如下：
protected string _orderId = string.Empty; protected string _orderNum = string.Empty; protected MerchantPayInfo _merchantPayInfo = null; protected string _orderPrice; protected string _productName = string.Empty; protected string _orderType = string.Empty; protected HttpResponse Response; protected HttpRequest Request; log4net.ILog log = log4net.LogManager.GetLogger("myDemo"); /// <summary> /// 去支付 /// </summary> public abstract void GoToPay(PaymentParameter parameters); /// <summary> /// 支付同步回調 /// </summary> public abstract void PayReturn(); /// <summary> /// 支付異步回調 /// </summary> public abstract void PayNotify(); /// <summary> /// 支付前的初始化 /// </summary> /// <param name="parameters"></param> protected void PaymentInitial(PaymentParameter parameters) {...}
在PaymentInitial中為部分對象做初始化，這里不做贅述。
准備工作就緒，接下來我們開始調用支付接口，首先是支付寶，我們定義一個類，可以叫作AliPayment，在其構造函數中為支付商家賬號對象賦值，然后開始為我們的三個最重要的方法編寫實現：
public override void GoToPay(PaymentParameter parameters) { base.PaymentInitial(parameters); ......var submit = new Submit(_merchantPayInfo.Akey); //建立請求 string sHtmlText = submit.BuildRequest(sParaTemp, "get", "確認"); Response.ContentType = "text/html"; Response.Write(sHtmlText); Response.End(); } /// <summary> /// 支付后同步調用 /// </summary> public override void PayReturn() { ...... } /// <summary> /// 支付后異步調用 /// </summary> public override void PayNotify() {
......
}
這三個方法的實現在支付寶接口文檔的demo里有提供，大家可以參考。考慮到篇幅問題，這部分代碼就不貼出來了。
支付類型和方法都定義且實現完成，接下來就是調用了。考慮到可擴展性，我們希望調用部分的代碼在以后擴展時，都不需要修改，這里我們可以通過配置實現。類似於我們所熟知的“控制反轉，依賴注入”：調用者不構造被調用者的實例，由容器構造被調用者的實例，再注入到調用者。當前的系統框架並沒有引入控制反轉策略，沒關系，框架里沒有，我們可以自己寫個類似的。
這里可以通過反射來構造支付類型的實例，創建類型實例的代碼如下：
/// <summary> /// 創建對象實例 /// </summary> /// <typeparam name="T">要創建對象的類型</typeparam> /// <param name="assemblyName">類型所在程序集名稱</param> /// <param name="nameSpace">類型所在命名空間</param> /// <param name="className">類型名</param> /// <returns></returns> public static T CreateInstance<T>(string assemblyName, string nameSpace, string className) { try { string fullName = nameSpace + "." + className;//命名空間.類型名 //此為第一種寫法 object ect = Assembly.Load(assemblyName).CreateInstance(fullName);//加載程序集，創建程序集里面的 命名空間.類型名 實例 return (T)ect;//類型轉換並返回 //下面是第二種寫法 //string path = fullName + "," + assemblyName;//命名空間.類型名,程序集 //Type o = Type.GetType(path);//加載類型 //object obj = Activator.CreateInstance(o, true);//根據類型創建實例 //return (T)obj;//類型轉換並返回 } catch { //發生異常，返回類型的默認值 return default(T); } }
這里需要注意：我們所創建的支付類型必須要自己寫構造函數，否則無法通過此方法創建實例。
在輔助方案都完成之后，實際調用的地方代碼量是非常少的，我們看調用的代碼：
string className = ConfigurationManager.AppSettings[payCode]; payment = ReflectionHelper.CreateInstance<IPayment>("MyTestAssembly", "MyTestAssembly.Payment", className); PaymentParameter parameter = new PaymentParameter(); parameter.LocalPath = "/Pay/Payment"; parameter.OrderId = OrderId; parameter.OrderType = OrderType; payment.GoToPay(parameter);
配置的內容如下：
<!--支付寶支付方案類型配置，用於反射 Leon--> <add key="0" value="AliPayment" /> <!--財付通支付方案類型配置，用於反射 Leon--> <add key="1" value="TecentPayment" />
以上，我們完成了支付模塊的重構，當給到不同的參數時，能夠通過不同的支付平台進行支付，如支付寶：
財付通：
后續需要擴展支付平台時，這套方案也能輕松應對：只需添加支付類型並增加該類型的配置即可。
本篇文章重點描述可擴展性，其實歸根結底是降低模塊間的藕合度。系統開發初期追求效率，未必能考慮到系統后續的發展需求，此時適當的代碼重構是很必要的。“高內聚，低耦合”的思想應貫穿設計到開發的始終。其他模塊也可以按這套思路進行重構，增加代碼的可讀性、可維護性和健壯性。
曾有一位前輩和我說過：“重構的過程，是程序員進步最快的過程。”這句話分享給大家。