上一篇文章引來不少非議，筆者並非對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" />
以上，我們完成了支付模塊的重構，當給到不同的參數時，能夠通過不同的支付平台進行支付，如支付寶：
財付通：
後續需要擴展支付平台時，這套方案也能輕松應對：只需添加支付類型並增加該類型的配置即可。
本篇文章重點描述可擴展性，其實歸根結底是降低模塊間的藕合度。系統開發初期追求效率，未必能考慮到系統後續的發展需求，此時適當的代碼重構是很必要的。“高內聚，低耦合”的思想應貫穿設計到開發的始終。其他模塊也可以按這套思路進行重構，增加代碼的可讀性、可維護性和健壯性。
曾有一位前輩和我說過：“重構的過程，是程序員進步最快的過程。”這句話分享給大家。
