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进行通讯及验证

　　感谢大家一直以来的支持,正所谓赞得高尿得远！嘿嘿..