程序員的自我救贖---1.1： 解決方案命分層規範
《目錄》
《Winner2.0框架解決方案命分層規範》
初學編程，難免要從Hello Word開始，學習Winner框架首先要知道如何建一個項目。有了第一個項目的框架結構就知道如何施展自己的"增刪查改"。
Winner框架 依然遵從MVC模式，這裏我就不去贅述什麽是MVC。
數據層：以"項目名.DataAcces"命名，例如： Shop.DataAccess；
實體層：以"項目名.Entities" 命名 例如： Shop.Entities；
業務層：以“項目名.Facade”命名 例如：Shop.Facade；
顯示層：以“項目名稱” 命名 例如： Shop；
=======================華麗的分割線====================
winner 框架的核心庫有 三個:
Winner.Framework.Core （核心類dll） Winner.Framework.Encrypt （加密類dll） Winner.Framework.Utils （工具類dll） 整個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、
=======================華麗的分割線====================
DataAccess 數據訪問層： 只存放由代碼生成器生成的數據訪問類,以及我們使用 “部分類” 自己根據需求擴展的數據庫操作 這裏我們使用 “部分類” 部分類，也叫分部類，這裏就不科普C# 語言基礎知識了。（關於代碼生成器，在下一篇中再詳細概述） 如下圖：
註意： 由代碼生成器生成的 文件名規範為："表名.generate.cs" 自己擴展的不含“generate”字樣以此區分。
代碼生成器，會幫我們生成實體 和 數據庫操作類，Winner框架將單條操作和 多條操作分成了兩個類。
但是這兩個類在同一個文件裏，數據庫操作類是以表為單位建文件。
這是代碼生成器生成的帶條操作，如果要根據需求擴展操作 著負責該類文件到Generate文件外,並刪除文件名中的.generate。 類文件中保留引用，命名空間，類名，刪除裏面的方法。
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 業務層：
業務層用來，處理邏輯業務。一個業務一個類文件，業務類繼承FacadeBase，而在Facadebase中集成了如：log4net，事務等功能。 在後面的篇章中會詳細介紹Facadebase。 命名規則為： “業務名Facade.cs” 如下圖：
我們的業務層，基本只返回bool類型。遵從面對對象的封裝思想，就如同ATM機一樣。只有一個插卡的“入口”，然後輸入“參數“”密碼 最後只有一個“出口”，出錢出來。 業務層裏面的方法沒有特別要求命名規範，遵從駝峰命名法即可。
這裏，好多新人加入我們團隊的時候就好奇這個事務居然不要在數據庫中寫，這個在後面的篇章中再詳細講，總而言之我們遵循一個原則：
數據庫的職責是做存儲數據，我們盡可能不去把業務邏輯放在數據庫中去處理。
這裏還出現了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有自己的一套前端這樣也能省很多事。
不過，我的終極想法是，代碼生成器能直接生成前端，這樣就更省事了。
好吧，關於解決方案的命名和結構就寫到這裏。
程序員的自我救贖---1.1： 解決方案命分層規範