应用程序框架实战二十九:Util Demo介绍

　　上文介绍了我选择EasyUi做为前端框架的缘由，并发放了最新Demo。本文将对这个Demo进行一些介绍，以方便你可以顺利运行起来。

　　这个Demo运行起来之后，是EasyUi的一个简单CRUD操做，数据库中也只有一个简单的表，整个操做不带任何业务逻辑。

　　看到这里，很多朋友不免感到失望，搞这么复杂一个架构，就只用来实现一个简单的CRUD操做，不是大炮打蚊子吗？

　　不要急，个人目的不是教你如何实现CRUD，我尚未这么无聊，我是但愿经过这个简单的CRUD操做，帮你引出一些框架特性，大体包括下面内容。

1. 分层架构，虽然是一个简单的CRUD，但基本的构造块都包含进来了，还有一些没介绍到的构造，好比领域服务等，我会在后续提供其它示例时再引入。我前面也已经介绍过一些构造，还没介绍到的会补上来。
2. 抽象和封装CRUD操做，虽然CRUD貌不惊人，但不论多复杂的系统，多少有一些CRUD的机械工做，对于简单的系统，CRUD则占据大半江山，因此对CRUD抽象和封装是有必要的。
3. Mvc控件封装，我将以封装EasyUi控件为例，为你详细介绍如何把Html封装起来，并使用Lambda表达式为你作更多的工做。
4. 依赖注入，对于这种比较复杂的架构，依赖注入框架是必须的，若是没有它，这种架构用起来就很是痛苦了。
5. 查询封装，我已经花了不少篇幅来介绍对查询的一些封装支持。经过这个示例为你介绍简单查询，你会感觉到查询封装的必要性，你平时那些杂乱无章的查询条件判断已经消失无踪了。对于复杂的查询，须要配合Linq 语句，更复杂的采用Sql，我之前经过存储过程的方式解决，不过发现分页和条件判断不太方便，最近我将Dapper引入，并封装了Sql查询组件，用来自动拼接Sql，提供了条件自动判断和分页等功能，待有须要的时候我会放出给你们参考。
6. 全局异常处理。经过一个简单的全局异常处理模型，并配合自定义异常Warning，能够解决大部分异常处理问题。
7. 日志封装。系统一旦部署出去，你的断点调试就无论用了，这时查找问题将主要依赖日志。哪怕在开发阶段，断点调试也不是一个高效的排错手段，一般在查看日志没法解决问题时才进行断点调试。大部分人采用Log4.Net进行日志处理，是否是引入Log4.Net就万事大吉了呢。Log4.Net只是一个底层组件，帮你把须要记录的信息保存一下而已。至于须要记录哪些信息，这是你应该考虑的，若是你的每条日志都须要记录大量的系统信息，好比Ip、线程号一类的东西，你不进行封装，就意味着开发人员每次调用日志组件时，须要本身手工设置。日志更高级的用法，甚至能帮你进行性能调优。
8. Excel文件导出封装。文件导出是一个常规操做，大部分时候都会导出为Excel格式。我之前采用简单的CSV格式，CSV格式使用逗号分隔各列数据，主要优点是简单，毛病是没有样式，更别说多表头。本次引入NPOI，并对多表头设置进行了高度封装，以你们熟悉的RowSpan和ColumnSpan的方式进行设置，大副简化了NPOI的操做。
9. 测试数据生成。咱们平时开发一个新模块，为了进行测试，通常须要录入一些数据，这些操做多半是手工进行。大部分人都知道偷懒，只是意思一下，随便录入几条，不过不少问题只有达到必定数据量才能有效测试。经过几个简单扩展和封装，就能够为简单模块生成批量测试数据。
10. 代码生成。不管如何努力的封装和抽象，你最终发现仍是有一些代码须要来回复制，这就是代码生成器上场的时候到了。我将为你简单介绍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/