系列目錄
前言：
起初寫這個框架的時候，可以說在當時來說並不是很流行的設計模式,那是在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進行通訊及驗證
寫在最后
感謝大家一直以來的支持,正所謂贊得高尿得遠！嘿嘿..
