C#大型電商項目優化（三）——擴展性與支付

上一篇文章引來不少非議，筆者并非對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" />

以上，我們完成了支付模塊的重構，當給到不同的參數時，能夠通過不同的支付平臺進行支付，如支付寶：

財付通：

后續需要擴展支付平臺時，這套方案也能輕松應對：只需添加支付類型并增加該類型的配置即可。

本篇文章重點描述可擴展性，其實歸根結底是降低模塊間的藕合度。系統開發初期追求效率，未必能考慮到系統后續的發展需求，此時適當的代碼重構是很必要的。“高內聚，低耦合”的思想應貫穿設計到開發的始終。其他模塊也可以按這套思路進行重構，增加代碼的可讀性、可維護性和健壯性。

曾有一位前輩和我說過：“重構的過程，是程序員進步最快的過程。”這句話分享給大家。