程序員的自我救贖---1.1： 解決方案命分層規範

《前言》

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

（二）PLSQL報表系統

（三）SSO單點登陸

（四） 短信中心與消息中心

（五）錢包系統

（六）GPU支付中心

（七）權限系統

（八）監控系統

（九）會員中心

（十） APP版本控制系統

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

（十二）上層應用案例

（十三）總結

 

 

《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有本身的一套前端這樣也能省不少事。

不過，個人終極想法是，代碼生成器能直接生成前端，這樣就更省事了。

 

好吧，關於解決方案的命名和結構就寫到這裏。