《Winner2.0框架解決方案命分層規范》
初學編程，難免要從Hello Word開始，學習Winner框架首先要知道如何建一個項目。有了第一個項目的框架結構就知道如何施展自己的"增刪查改"。
Winner框架 依然遵從MVC模式，這里我就不去贅述什么是MVC。
數據層：以"項目名.DataAcces"命名，例如： Shop.DataAccess；
實體層：以"項目名.Entities" 命名 例如： Shop.Entities；
業務層：以“項目名.Facade”命名 例如：Shop.Facade；
顯示層：以“項目名稱” 命名 例如： Shop；
=======================華麗的分割線====================
winner 框架的核心庫有 三個:
=======================華麗的分割線====================
數據庫命名：
1.基礎規范：
1.由於Oracle做大小寫命名非常麻煩，所有統一采用PLSQL規范為大寫。為了命名的可讀性，每個單詞與單詞之間用下划線（“_”）隔開。
2.每個表、字段、試圖都必須加上相關備注；
3.每個表的字段最后必須加上Remarks與Create_Time（默認為sysdate）字段；
4.凡是有字段在程序中為枚舉的，則需要在備注中寫明枚舉名稱和枚舉值，例如用戶狀態的備注為：用戶狀態$UserStatus${未激活=0,已激活=1,已鎖定=2}
2.命名規范：
1.表名： T模塊_表名 例如：用戶模塊用戶表，Tnet_Reginfo
2.試圖： V模塊_表名 例如：用戶模塊用戶表，Vnet_Reginfo
3.主鍵： PK_表名 例如：PK_Tnet_Reginfo
4.外鍵： FK_表名_字段 例如：FK_Tnet_Reginfo_NodeId
5.唯一鍵： UK_表名_字段 例如：UK_Tnet_Reginfo_NodeCode
6.檢查約束： CK_表名_字段 例如：CK_Tnet_Reginfo_NodeCode、
=======================華麗的分割線====================
代碼生成器，會幫我們生成實體 和 數據庫操作類，Winner框架將單條操作和 多條操作分成了兩個類。
但是這兩個類在同一個文件里，數據庫操作類是以表為單位建文件。
XXX_XXXXCollection 類中所有的查詢類要求統一以List開頭例如： ListUserByStr()；ListUserByAccount()；關於繼承的DataAccesBase 和 DataAccessCollectionBase 在后面的篇章中會詳細講到。
這里有一條要注意,winner框架是集成了，數據訪問類。整個項目只需要通過配置即可訪問數據庫，不需要再畫蛇添足的去寫數據庫訪問類，我們團隊曾經有個新入職的員工，不是特別懂框架開發了兩天
進度一直沒上來，結果他一個人自己閉門造車寫數據庫訪問層，如果這些最基礎的工作每個項目都要開發者來重復做一遍就不能稱之為框架了。 我們很長一段時間開發中有新的公用類，或者比較常用的工具
我們都會集成到框架里來，整個框架除了 三個 核心dll，擴展的dll 以及第三方的dll加起來有一兩百個，比如常見的：NPOI，Newtonsoft，SQLite。這些在TFS中的dll文件夾中都有的，而且一直在更新。
================================華麗的分割線==============================
Entities 實體層：
一般我們Winner框架的代碼生成器會自動生成表所對應的實體以及字段在DataAccess中，但是我們實際開發中經常要跨應用對接
比如要跟Android對接、IOS對接，這個時候我們很多情況下要自己 寫Model，並根據model 序列化Json。 所以Entities 主要職責是存放model，
除了，存放model實體以外Entities還有另外三項職責，總的來說如下四點：
1，存放實體Model
2，存放枚舉對象
3，保存產量，或變量。
4，存放該項目需要的工具對象。
如下圖：
上面還有很多，比如根據項目需求寫RAS加密工具類，基本上能公用的阿傑都寫在了Winner.Framework.Encrypt 和 Winner.Framework.Utils。
====================================華麗的分割線===============================
Facade 業務層：
這里，好多新人加入我們團隊的時候就好奇這個事務居然不要在數據庫中寫，這個在后面的篇章中再詳細講，總而言之我們遵循一個原則：
數據庫的職責是做存儲數據，我們盡可能不去把業務邏輯放在數據庫中去處理。
這里還出現了Alert()方法，這個也是從FacadeBase中繼承而來，在調用業務Facade的時候，我們可能直接拿出Facade業務對象返還的Message錯誤信息。
在后期的項目篇章中這個Alert() 會出現很多。
另外，這里我們也有一個寫Facade業務的基礎思想“水渠思想”，就像河水變成自來水的過程，要經過多到工序，有一步有問題我們就結束。
所以，我們就一層層的判斷。 但不是 用嵌套if去寫， 而在if判斷為false之后 直接return，為true 就執行下一步。
（好比：“河水過濾失敗，不能進行下一步，返回。過濾成功，下一步開始殺毒，殺毒失敗返回，殺毒成功，開始氯洗····一直到最后成功”）
中間每一筆以事務管理起來，失敗就RollBack()，成功則Commit()。
====================華麗的分隔線=====================
項目 顯示層：
最后的顯示層，以前我們用的是Asp.Net，我們會有TopPageBase基類 和 CommPageBase，TopPageBase沒有驗證登錄信息，
是給不需要登錄的界面繼承的，而繼承了CommPageBase 的頁面則必須要登錄。 當然還有相應有很多前端插件，比如分頁控件，日歷控件等等。
但是現在.net主要都是使用 .net MVC了。 所以我們單獨也有一個程序集 Winner.FrameWork.Mvc.dll。
如下圖：
自此也Winner框架的解決方案也就描述的差不多，我們前端沒有形成自己的一套JS庫，更多的還是使用第三方庫。常規的JQuery 和 KnockOut
我就不再做描述，這方面我個人也用的不好，在這方面Jason和阿jie 都非常厲害。
遺憾的是Winner框架 沒有形成一套Winner前端的后台模板。相對Ace UI模板用的比較多，另外 Amaze UI 也有一些。
阿傑說他有寫一套前端，目前在團隊內部推廣。如果沒問題，我也希望Winner有自己的一套前端這樣也能省很多事。
不過，我的終極想法是，代碼生成器能直接生成前端，這樣就更省事了。
好吧，關於解決方案的命名和結構就寫到這里。