前言：
起初写这个框架的时候，可以说在当时来说并不是很流行的设计模式,那是在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进行通讯及验证
写在最后
感谢大家一直以来的支持,正所谓赞得高尿得远！嘿嘿..
