《前言》

《目錄》

（一） Winner2.0 框架基礎分析

（二） 短信中心

（三）SSO單點登錄

（四）PLSQL報表系統

（五）錢包系統

（六）GPU支付中心

（七）權限系統

（八）監控系統

（九）會員中心

（十）消息中心

（十一）Winner前端框架與RPC接口規範講解

（十二）上層應用案例

（十三）番外篇

《代碼生成器的使用》

今天中午阿傑聊了會，阿傑說看了我寫的博客後。發現一個問題，把Winner框架整理成文檔，要把Winner框架的核心思想

給寫出來，比如為什麽要選擇Winner框架，市面上用於開發框架很多，比如以前我們剛工作的時候用的“動軟代碼生成器”，又或者

後來的EF，T4 等等。

其實，我的工作生涯中用過的代碼生成器和框架只有2個，從技術上的層次來說沒辦法達到阿傑他們那樣的高度，這也導致了我

沒辦法將Winner框架與其它框架的優缺點一一進行對比。當然，每個框架自然有他的好處，這個是毋庸置疑的。用我老師以前的口頭禪

說就是：“存在即合理！”

我想了想，還是根據我的理解來寫。不一定能寫出Winner的精髓，後期只能像阿傑他們請教了。就代碼生成器而言我就重點對比一下

“動軟代碼生成器” 和 "Winner 代碼生成器"。

其實，我個人的觀點動軟的代碼生成器界面是比我們的Winner代碼生成器 要美觀一點，但是代碼生成器的職責是生成代碼，而生成代碼的關鍵因素是“模板”。

待會我再詳細講模板。

這裏先說一下數據庫，由於本身 Sqlserver 和 .Net 一脈相承，所以微軟本身會更推薦使用Sqlserver數據庫，sqlserver本身也易於操作，一直以來江湖傳言

在大型項目開發一定要用“Oracle”，Oracle性能比sqlserver 如何如何好，這裏其實我沒有做過詳細的測試。姑且聽之信之，Sqlserver方面我們沒有深入了解過，

使用Oracle的時候，對集群，備份 ，性能分析 等等方面 Oralce確實有很多優先的方案，比如“RAC”，“DataGuard”，“Rman” 等等（我們選擇Oracle也是因為當遇到問題時網上能找到詳細的解決方案）。

事實我們也看過很多案例比如做支付領域，物流領域。數據較大的行業基本都是Oralce為主，當然也有組合數據庫使用（包括NO-sql）。

所以，Winner一直以來首選 的數據庫是Oracle，當然也不局限於Oracle。這裏特意說一下數據庫方面，回到主題上來。“動軟” 一開始我估計就是為sqlserver設計的

所以在代碼生成上有一項功能我非常喜歡，動軟可以根據實例 一鍵生成 整個項目。這點Winner則做不了，主要是因為Oracle一安裝就只有一個實例，下面再是分用戶分空間的。

我們沒有把Oracle玩的那樣的嫻熟，前面的篇章中我也有講到，因為我們的思想上一直認為“數據庫”的職責是做數據庫持久化存儲，所以我們所有的項目表都是

建在一個Oracle用戶下，技術員我們會單獨分配“賬戶”，這裏的“賬戶”不是指的Oralce用戶。 再對“賬戶”進行表操作權限分配。

按下F5鍵，代碼生成窗口，檢索並選擇要生成的數據表，添加 生成，搞定。

在上一篇《Winner2.0框架解決方案命分層規範》 中有特別講到過數據庫的命名規範，也體現了命名規範的重要性，在檢索項目的時候，我們只要輸入T項目項目 即可檢索出該

項目所有的數據表， 在整個數據庫中，這也規避了如A項目有個地址表，B項目也有個地址表，且兩個地址表不能共用。這時就可以通過前綴來區分開來。

在數據庫的支持上來說兩者差不多，兩者沒有什麽優勢可言。Winner一直以來都是團隊內部使用的代碼生成器，這次其實也想通過公開它來讓更多人提出意見使它更完善。

========================================華麗的分割線=================================

接下來說說重點： 模板

先從解決方案說起，動軟遵循MVC原則，常規項目分為以下四層：

1，Dal 數據訪問層

2，Model 實體層

3，Bll 業務層

4，項目顯示層 （View）

其中 Dal，Model，Bll 都由代碼生成器生成三份文件，復雜業務邏輯放置BLL業務層處理。

Winner，當然也是遵循MVC原則 同樣遵循MVC原則，常規項目也是分為四層

1，Access 數據訪問層

2，Entities 實體層。

3，Facade 業務層

4，項目顯示層 （View）

其中只有Access 數據訪問層由代碼生成器生成。 （關於結構可以先瀏覽《Winner2.0框架解決方案命分層規範》）

這裏有以下幾點我們在項目開發中與動軟有很大的區別。

A： 動軟的框架中“工具層” 這一概念，如果需要使用到一些工具的話，需要自己建一個“Common”工具層，當然這個有很多前輩高人，都有

一套自己的“工具類”，只需要引用一個程序集就好。在這一點上，Winner框架中當然有專門的工具類Winner.Framework.Utils ，有其他要寫

工具類需求的時候，Winner框架可以再Entities層中添加。當然，這點只是個“區別”，沒有上面優劣可言。

B：動軟架構中，生成三份文件本意是讓職責更清晰，這點與Winner架構的概念不一樣，Winner框架意在簡歷一個表對象，更貼合“面向對象”思想。

將“數據表”看做是一個對象，這個對象有基本的行為“增刪查改”，這個對象有基本的特征“字段對應屬性”。 對象的概念更清晰，相對動軟的一層層

去調用，和 Winner的操作表對象，我的理解就是一個是“面向過程編程”，一個是“面向對象編程”。當然也有可能是我沒用好動軟，又或者是指用了

動軟最基本的架構。 這裏要說一下，EF也基於“表對象”概念 對表進行操作。

C：Winner有效的區分開了哪些是有代碼生成器生成的代碼，哪些是由程序員自己擴展的代碼，如下圖：

這樣的好處是，當我數據庫表字段更新的時候，我只需要代碼生成器生成一份新的代碼並復制--粘貼到GenerateCode文件夾即可，

默認的動軟框架DAL中可能添加了很多自己根據業務擴展的方法，這個時候，要不就從代碼生成器預覽中一個方法一個方法的復制過來

要不就只能把自己寫的代碼復制到txt，然後更新DAL類後再復制回去。

《Winner2.0框架解決方案命分層規範》 中有帶著講到一點，Winner框架中“部分類的應用”，這裏再貼圖詳細說明一下。

上圖為代碼生成器生成的Tnet_lock 表的DA類，下圖為根據業務擴展的 Tnet_lock類

其實，DA生成的類對象，是一個類文件中，寫了兩個類一個是單條數據操作，一個是集合數據操作。更準確的說是 一個DA對象 是由四個分部類組成

生成的單條數據DA部分類， 擴展的單條數據DA部分類；

成生的集合數據DA部分類， 擴展的集合數據DA部分類；

其他的DA中只返回成功或失敗，取值直接從DA的屬性去取：

D，動軟基本是教科書式的範例， View》 BLL》DAL 。（“》”代表調用）View不直接調用DAL，所以動軟架構中BLL一些方法只是包裝了一層DAL，

這裏其實是多余代碼。Winner，表操作中我們直接實例化Access對象，再填充表字段對應的Access屬性，最後調用如Update(),Insert() 方法即可。

拿上面的修改銀行卡信息舉例，動軟框架的操作相比之下就要復雜的多：

View中調用BLL-----》BLL調用DAL----》BLL實例化Model------》BLL將查詢結果填充Model----》修改Model-----》調用DAL中Update()傳入model;

動軟的則要復雜的很多。

E：說一個動軟的優點，動軟代碼生成器有一個功能我也非常喜歡，動軟生成器有數據庫字典生成的功能，這個winner代碼生成器沒有，當然可以做

只是作為一個公司內部使用的工具，我們一直沒有去做。說白了，也是我們公司畢竟還是小公司方方面面施展不開，沒有把架構小組給立起來。

=======================華麗的分割線=========================

最後貼一下，動軟生成器 和 Winner生成器的模板，有興趣的可自行下載動軟生成器詳細查看，至於Winner代碼生成器，我今天建了一個Winner2.0框架群

可以加我們的QQ群即可。

代碼生成器的原理都是寫好模板，然後再根據模板進行關鍵字替換，如果有興趣自己寫代碼生成器的可以自行百度，這裏我不推薦自己寫

代碼生成器，推薦使用“CodeSmith”，基於CodeSmith的語法（關鍵字） 自己定義模板即可，這樣可以省去很多對數據庫操作的功能代碼編寫。

關於代碼生成器的部分就寫到這裏，最後再補充一下：代碼生成器只是節約重復性工作時間的一種工具，關鍵的還是思想。整個Winner代碼生成器

最重要的思想是“對象化”。無論是用EF，還是動軟，面對對象的思想能明確，代碼就能寫的靈活。 而代碼生成器本身也是一種“封裝”思想。將能公用、共用的

操作封裝起來，方便程序員調用，而這個調用不是指程序中的調用，是指開發項目的“調用”。

程序員的自我救贖---1.2：代碼生成器的使用