上文介绍了我选择EasyUi作为前端框架的原因，并发放了最新Demo。本文将对这个Demo进行一些介绍，以方便你能够顺利运行起来。
这个Demo运行起来以后，是EasyUi的一个简单CRUD操作，数据库中也只有一个简单的表，整个操作不带任何业务逻辑。
看到这里，不少朋友难免感到失望，搞这么复杂一个架构，就只用来实现一个简单的CRUD操作，不是大炮打蚊子吗？
不要急，我的目的不是教你如何实现CRUD，我还没有这么无聊，我是希望通过这个简单的CRUD操作，帮你引出一些框架特性，大致包括下面内容。
- 分层架构，虽然是一个简单的CRUD，但基本的构造块都包含进来了，还有一些没介绍到的构造，比如领域服务等，我会在后续提供其它示例时再引入。我前面也已经介绍过一些构造，还没介绍到的会补上来。
- 抽象和封装CRUD操作，虽然CRUD貌不惊人，但不论多复杂的系统，多少有一些CRUD的机械工作，对于简单的系统，CRUD则占据大半江山，所以对CRUD抽象和封装是有必要的。
- Mvc控件封装，我将以封装EasyUi控件为例，为你详细介绍如何把Html封装起来，并使用Lambda表达式为你做更多的工作。
- 依赖注入，对于这种比较复杂的架构，依赖注入框架是必须的，如果没有它，这种架构用起来就非常痛苦了。
- 查询封装，我已经花了很多篇幅来介绍对查询的一些封装支持。通过这个示例为你介绍简单查询，你会感受到查询封装的必要性，你平时那些杂乱无章的查询条件判断已经消失无踪了。对于复杂的查询，需要配合Linq 语句，更复杂的采用Sql，我以前通过存储过程的方式解决，不过发现分页和条件判断不太方便，最近我将Dapper引入，并封装了Sql查询组件，用来自动拼接Sql，提供了条件自动判断和分页等功能，待有需要的时候我会放出给大家参考。
- 全局异常处理。通过一个简单的全局异常处理模型，并配合自定义异常Warning，可以解决大部分异常处理问题。
- 日志封装。系统一旦部署出去，你的断点调试就不管用了，这时查找问题将主要依赖日志。哪怕在开发阶段，断点调试也不是一个高效的排错手段，通常在查看日志无法解决问题时才进行断点调试。大部分人采用Log4.Net进行日志处理，是不是引入Log4.Net就万事大吉了呢。Log4.Net只是一个底层组件，帮你把需要记录的信息保存一下而已。至于需要记录哪些信息，这是你应该考虑的，如果你的每条日志都需要记录大量的系统信息，比如Ip、线程号一类的东西，你不进行封装，就意味着开发人员每次调用日志组件时，需要自己手工设置。日志更高级的用法，甚至能帮你进行性能调优。
- Excel文件导出封装。文件导出是一个常规操作，大部分时候都会导出为Excel格式。我以前采用简单的CSV格式，CSV格式使用逗号分隔各列数据，主要优势是简单，毛病是没有样式，更别说多表头。本次引入NPOI，并对多表头设置进行了高度封装，以大家熟悉的RowSpan和ColumnSpan的方式进行设置，大副简化了NPOI的操作。
- 测试数据生成。我们平时开发一个新模块，为了进行测试，一般需要录入一些数据，这些操作多半是手工进行。大部分人都知道偷懒，只是意思一下，随便录入几条，不过很多问题只有达到一定数据量才能有效测试。通过几个简单扩展和封装，就可以为简单模块生成批量测试数据。
- 代码生成。无论如何努力的封装和抽象，你最终发现还是有一些代码需要来回复制，这就是代码生成器上场的时候到了。我将为你简单介绍CodeSmith，以及CodeSmith自带的EF Code First模板，你会发现简单修改就可以用于生产环境了。不仅如此，还会把我整理的CodeSmith模板分享出来，这套模板是根据Util量身定制的。
在看完以上介绍后，希望你能够增强对本系列文章的信心。
我这个系列主要分享的是应用程序框架的搭建和封装经验，这些代码只是给你参考用的。我并不会随时关注性能问题，因为我平时的项目要求并不高，所以代码中总是采用最省力的方式，比如反射，查询时获取全部字段等，我仅在确实碰到性能问题时才进行局部调优。
下面先介绍Demo的目录结构。
Applications包含一个VS解决方案，它是你能够运行的应用程序，这个解决方案采用了DDD架构分层。
为了示例的真实性，我将应用程序和应用程序框架分到了两个VS解决方案中，这一点非常重要，这样可以显著减少应用程序的编译时间，另一个好处是可以对团队成员透明，减少复杂度。所以Applications依赖一些DLL，这些DLL被指定到一个目录，这就是Release。管理DLL有很多方式，标准方式是Nuget，如果你喜欢，请自行创建。
Util目录包含另一个VS解决方案，这个就是应用程序框架。我已经将Release目录中的DLL删除，这样做是为了节省空间，你只需要编译Util解决方案，相关的DLL就会生成到根目录的Release中，这是因为我更改了每个类库的生成路径。
当你打开Util解决方案，你会发现某些项目中包含名称为00-Source的目录，这个目录中包含了某个第三方开源框架的源码，这样做的唯一原因是为了减少生成的DLL。如果你以后也准备这样干，需要注意将该开源框架的条件编译符号复制到你的项目。
TestBin目录用于放置测试项目生成的DLL，没有特别的用途，只是方便统一管理测试DLL，以免每个目录都包含一堆垃圾。
Libraries目录是依赖的一些第三方DLL。
Data目录包含一个Sql Server 2005的备份文件，里面是一个单表，有1万行测试数据。
上面介绍了目录情况，现在你得把Demo运行起来。
第一步打开Util解决方案编译。
第二步打开Applications中的解决方案，编译。
第三步还原Sql Server数据库，记住还原，不要附加。
第四步修改连接字符串，这些基础的不要我说了吧。
第五步，设置Managements.Presentation项目为启动项目，运行。
如果没什么意外的话，你应该能跑起来了，如果不行，注意你的开发环境与我的可能有差异。我使用的是VS 2013,MVC 4.0,还有一些人发现他的MVC版本是4.0.1，你本机如果没有Mvc 4.0的DLL，找别人给你发几个4.0的DLL就可以了。
目前发出的Demo没有包含上面所述的全部功能，我会在即将介绍到相关功能时更新，请关注。
还有些朋友反应看不太懂，不要急，这是正常人的反应，看别人的东西总是很头痛，你可以暂时不要看Util解决方案，先把Applications解决方案看熟，我后面会逐步介绍各构造块。
后续Demo，不再通过EMAIL方式发放，以免污染评论区。
最后，希望大家狂点推荐，少点反对，嘿嘿。
.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。
谢谢大家的持续关注，我的博客地址：http://www.cnblogs.com/xiadao521/