应用程序框架实战三十五:服务概述

　　上一篇介绍了我对几种实体的认识，本篇将介绍几种服务的用法。

　　预告一下本系列后续计划，本篇以后，准备进入实战演练阶段，先介绍如何快速解决CRUD操做，从如何使用PD数据建模到使用CodeSmith生成代码，先带你感觉一下，再回过来介绍框架内部元素，以避免你在阅读时昏昏欲睡。

应用服务介绍

　　对于一个新的设计元素，能够先假定不须要它，等到确实认识到它的做用再引入。那么，应用服务为咱们带来了哪些好处呢？

应用服务帮助简化表现层操做

　　以MVC为例，若是没有应用服务，那么控制器将直接调用仓储，设置查询条件，转换DTO等。

　　当控制器操做变得复杂，你会想办法把控制器代码分离出去。分离控制器代码的最好方法就是创建对应的应用服务，不要轻易的分离控制器自己，由于这会致使查找视图变得困难，而且破坏了约定，致使更高的维护成本。

应用服务为表现层提供惟一的API访问点

　　当一个控制器操做变得复杂时，编写控制器的程序员须要了解更多的知识，这些操做是由哪些聚合、领域服务、基础设施服务等构造元素组装起来的呢，调用顺序如何？

　　这是表现层应该关心的问题吗？

　　表现层应该只关心界面展现，这是表现层的基本职责所在，其它职责尽可能转移到后方。

　　应用服务将细粒度操做打包为粗粒度操做，让编写表现层的程序员再也不东张西望，他只须要记得一件事：须要访问任何后端的操做，找应用服务就对了。

应用服务为多个表现层减小冗余代码

　　若是须要多个表现层，好比须要开发一个WPF程序，功能与MVC彻底同样，这时候，你会发现表现层充斥大量重复代码。

　　引入应用服务后，表现层代码更简洁，冗余代码更少，建立多个表现层更加轻松。

应用服务集成和装配领域层与基础设施层

　　为了保持领域层的纯净，咱们采用依赖倒置原则，领域层只拥有操做接口，具体实现却在基础设施层，最终要能运行起来，必须将它们组装到一块儿。

　　若是没有应用服务，控制器将须要本身进行装配，这增长了表现层的负担，应用服务承接了这项工做，让表现层专心干本身的本职工做。

应用服务配合DTO优化远程调用性能

　　当采用了分布式架构，为了提高性能，须要尽可能减小远程调用次数。        

　　应用服务在分布式环境充当了远程外观，配合DTO一块儿解决这个问题。

应用服务与BLL的比较

　　对于长时间采用传统三层架构的朋友，对于应用服务这个构造是无比的亲切，初步用起来之后，你发现这个应用服务就是BLL的翻版。

　　BLL是传统三层架构的业务逻辑层，不少人直接用BLL来命名业务逻辑层的服务类，我暂时就用这个称呼。      

　　BLL是业务逻辑放置的场所，BLL将结果保存到Model实体类中，而后将实体类传递给其它层。

　　应用服务用于协调领域层与基础设施层的操做，应用服务自己不该该完成复杂的业务逻辑。

　　应用服务与BLL的关键区别在于，BLL直接完成业务逻辑，而应用服务会将业务逻辑委托给领域实体或领域服务。

　　从代码上看，BLL主要经过操做Model的属性进行业务逻辑的处理，而应用服务经过调用领域实体或领域服务的方法完成全部业务操做。        

领域服务介绍

　　从前面的介绍，你应该已经发现应用服务是有用的，下面再来看看领域服务。

　　在最理想的状况下，全部的业务逻辑都应该高度内聚到聚合中。但对于更复杂的业务，通常都有比较复杂的流程，这些流程上的控制，放入聚合并不合适，由于这些行为不属于某个聚合。

　　若是把这些行为放到应用服务中，可能致使应用服务很是复杂，业务逻辑也从领域层脱离出来，使业务逻辑的管理更加困难。

　　为了把业务逻辑从新移回领域层，须要添加一个领域服务。

　　如今咱们有了应用服务和领域服务两个构造元素，那么，对于一个复杂操做，应该将哪一部分放入应用服务，哪些又放到领域服务呢？

　　书上介绍，业务逻辑可分为领域逻辑和应用逻辑，领域逻辑应该彻底放到领域层，不能泄露到其它层去，而应用逻辑应该放到应用层服务。

　　能够看出，说得至关抽象，哪一种东西算得上领域逻辑，哪一种又是应用逻辑？这个很难精确划分。

　　一个经典的应用逻辑例子是事务控制，事务控制不是客户的需求，但却很是重要，因此把这种东西放到应用层，而不是领域层。

　　那么发邮件的操做是领域逻辑，仍是应用逻辑？？有人说是领域逻辑，有人说是应用逻辑，还有人说要看状况。可谓众说纷纭，让你摸不着头脑。

　　不过咱们学习的目的不是进行学术辩论，而是切实的提高项目可维护性，因此不用太理会那些考智商的概念，下面谈谈个人用法。

　　对于应用服务，我老是须要它，由于它能够简化表现层开发。

　　对于某些比较简单的业务逻辑，若是发现创建领域服务并未产生太大价值，我就直接放入应用服务中。好比判断一个实体的名称不能重复，这是一个业务需求，首先考虑这个业务逻辑能够放入实体中吗？不能，由于实体自己没法了解本身的名称有无重复。其次考虑须要创建领域服务吗？对于这种简单业务逻辑，建立一个领域服务有点大炮打蚊子的感受。我会直接将重名检测放入应用服务中，虽然致使有一点业务逻辑散落到应用层，但我未发现对可维护性形成影响。

　　若是业务逻辑比较复杂，我通常会采用TDD方式推动业务开发，这种状况下，创建领域服务是一个极好的选择，由于领域层依赖低，单元测试更方便。

　　不论应用服务，仍是领域服务，开发的基本原则是，尽可能将业务逻辑委托给领域实体，服务仅作调度的工做。

　　基础设施服务比较好理解，就是提供一些基础支持服务，好比发送邮件等操做。

须要为服务抽取接口吗

　　学习设计模式时，要求咱们面向接口编程，但一些对象大师建议不要过分设计，以避免致使没必要要的复杂性，在《实现领域驱动设计》一书中提出，应用服务使用独立接口没有什么好处。

　　虽然接口有很多做用，但通常来说，驱动建立接口的真正需求来自多态。在通常的项目开发中，特别是前期，服务不多具备多态需求，那咱们还要不要为服务创建接口?

　　在没有使用Resharper的年代，我使用接口很是当心谨慎，由于从接口定位实现类很是困难，但自从用上了Resharper，接口再也不成为障碍。

　　另外一方面，IOC框架的使用，让接口的使用进一步普及，我只须要将实现类绑定到接口，在程序中就能够自由使用了。虽然IOC能够直接绑定实现类，但总感受有点奇怪。

　　最后，对于跨层访问，采用接口互联也符合分层设计原则。

　　对于采用了Ioc框架，并安装了Resharper这样强大的工具，接口不会给你形成任何不便，至因而否致使复杂性，则须要本身体会。

　　代码中采用接口编程，可能在大多状况下都未产生实质的好处，但在需求发生变化时，只需修改Ioc配置替换相关实现，这个扩展性在不花成本的状况下仍是划得来的。

服务命名约定

　　当同时须要应用服务和领域服务，会发现服务取名也很困难。好比用户管理，应用服务叫UserService，若是须要领域服务，也叫UserService就发生冲突 ，但命名为其它可能又不合适。

　　个人办法是应用服务统一以Service结尾，领域服务统一以Manager结尾，这样就能够简单的解决这个问题。对于和我同样的英文菜鸟，可能特别有用。

最新源码发放

　　本次更新了EasyUi表格列绑定Combox和Combotree的功能。同时新增了一个图标管理模块，该模块包含对百度WebUploader上传图片控件的简单封装，服务端上传操做封装。

　　WebUploader控件很是给力，且提供的Demo很是好用，我基本直接COPY过来简单修改就用上了。

　　我在Data下载包中提供了一些图标，以方便你们操做。

　　同时，该示例包含了领域服务，并提供了相关的单元测试，你们能够参考。

　　下载截几个运行效果图。

       

　　虽然这个界面包含了树控件的CRUD操做，但总的JS代码量仍是比较少的。

 

下载时记得推荐：

http://files.cnblogs.com/files/xiadao521/Applications.2015.4.9.2.rar

http://files.cnblogs.com/files/xiadao521/Framework.2015.4.8.1.rar

http://files.cnblogs.com/files/xiadao521/Data.2015.4.8.2.rar        

 

.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。

.Net Easyui开发交流QQ群（本群仅限Easyui开发者，非Easyui开发者勿进）：157809322

谢谢你们的持续关注，个人博客地址：http://www.cnblogs.com/xiadao521/