ASP.NET MVC5+EF6+EasyUI 後臺管理系統（60）-系統總結

系列目錄

前言：

起初寫這個框架的時候，能夠說在當時來講並非很流行的設計模式,那是在2012年，面向對象的編程你們都很熟悉， 可是「注入、控制反轉(DI,IOC,依賴注入)、AOP切面編程」新興名詞

不少人並不知道特別是從事.NET開發的人，至少在當時 是這麼樣的，可是在今天它們倒是很是流行的技術指標，不少大牛也認可，這是主流的開發模式，大家能夠從招聘網的技術崗 位看出。

嘿嘿...

我從事過MVC2.0到5.0的相關開發工做，見證了MVC的成熟演變過程，就像本框架同樣，設計模式不曾改變，可是代碼一直在重 構。我也堅信這種開發模式目前沒法被取代，也是咱們Web開發工做的首選

MVCWebAPI適配移動設備接口，MVCWEB業務界面顯示處理，這是多麼的標配。

我爲什麼選擇這個技術組合？

我當初對技術的選型非常簡單，從簡單的開發方式和學習成本人員考慮，你們都認知的技術方式，能夠克服開發過程當中團隊人 員的更換（離職，新人）

選擇的技術都是從大流行架構精粹出來，並不使用很是大型的底層框架，培訓學習成本極高，從學習到開發須要一個漫長的過程，這也是老闆們不肯意看到的

同時也考慮到應用系統的使用負擔並非極大

So: Asp.net MVC、EF、IOC容器、EasyUI、分層分模塊、基於接口

MVC：目前適用全部前端應用的部署，包括網站，系統後臺，適配，API接口，沒有像webform,php等同樣的混合型臃腫代碼，關注點分離

EF：微軟件本身的東西，畢竟用起來很是順手，更新很快，支持主流的數據庫，易於擴展和變化，可是缺點咱們都知道，大型訪問量的系統並不適合

　　同時ORM顯然也沒有生的SQL語句來得更加直接，可是易用性和開發速度上毋庸置疑

注入：注入容器我在各大流行的IOC注入容器中選擇了Unity,在當時綜合來看,Unity在像流行的Autofac,Spring.NET等中，屬於中規中矩的穩定型，直到今天

　　通過多年的版本演變，各大注入框架的性能穩定性，和易用性都差很少，因此不管選擇那一款都好，咱們實現的效果都是同樣的，他們的原理也都是同樣的

EasyUI：對於應用系統，我認爲最重要的就是數據表格，處理和顯示覆雜的業務模式是必要的首選，EasyUI的組件應有盡有，我一度想換成Bootstrap，可是對於應用系統

　　BootStrap其實並不適合，特別是開發速度上和顯示上，雖然更加輕量級，可是你最後會爲交互撓破了你本身的頭，不信你能夠試試看。不過發佈於互聯網的界面可使用

　　BootStrap，互不衝突，最後我仍是看厭了EasyUI的皮膚，本身努力寫了5套Easyui的皮膚，其實並不難。傳送門

分層分模塊：從數據庫到文件的命名他們是有規範的，也是對系統的約定和編碼規範，每一家公司對編碼都有必定的規範，可是大同小一異，好比工做流模塊，Flow在數據庫表中是Flow_

　　爲前綴，在MVC中的Areas下爲Flow，BLL,DAL以,Flow.BLL,Flow.DAL。這都有利於開發人員的快速設別和T4的統一輩子成，也利於系統的拆分,同時咱們的BLL,DAL也適用於

　　WinForm，WPF等桌面軟件，或者作爲WebAPI的業務層。

基於接口：規範、約束、分離等，通俗點來講我主要做爲分包，業務代碼隱藏，團隊開發中只要定義好接口，而無須要實用業務，就能發包同時開發進行，很是好

如何閱讀本系列的文章

 理論上任何感興趣的園友均可以瞭解和閱讀，可是若是你具有必定的工做經驗那麼看起來事半功倍。

其中1-10節：是本系列的入門基礎。基本就肯定了從用戶請求到讀取數據庫的全過程，主要講解Easyui是如何讀取後臺數據，經過Json數據的交互方式，速度快無刷新，一樣適用其餘前段框架。如Extjs,jqgrid等等。

11,12,13節：是本系統的日誌、異常處理方式，日誌能夠記錄用戶的每一個動做，異常可讓開發人員快速獲得問題定位。

18-28節：權限是每一個應用系統最基本的東西，理論必須擁有。關鍵權限是控制程度，本系列把權限控制到按鈕級別，經過全局過濾器來處理請求

--------------------中間爲選讀章節------------------

58,59節是本系列的重構章節，經過T4模板，封裝了DAL,BLLMODEL'的重複代碼，代碼生成器的'BLL,DAL已經再也不須要。大大省掉了不少重複代碼，必須閱讀。就算你的系統並不屬於本系列的範圍，可是58,59也許對你有幫助

後續將帶來一些WebAPI的開放及驗證，讓WebAPI開放給移動端等文章，讓咱們知道安卓是如何與咱們的API進行通信及驗證

寫在最後

　　感謝你們一直以來的支持,正所謂贊得高尿得遠！嘿嘿..