项目架构开发：服务层（下）

之前我们已经完成了服务层，因为当时展现层还没有出来，所以只做了简单介绍。传送门：项目架构开发：服务层（上）

这次我们通过一个维护系统用户的场景来介绍一下服务层真正的设计用意。

1、新增用户场景

 新增用户可能会有以下步骤

实现以上需求，开发人员一般情况下可能就是以上 蓝红黑紫绿 几种选择 

1、有些写在Controllers、有些写在Application

2、都写在Controllers或都写在Application

3、有些写在DAL层、甚至存储过程

特别是新手以及那些拿来主义的人，他们不会花更多时间去思考。

分不清各层的职责以及界限，迷信那句：不管黑猫白猫，抓到老鼠就是好猫

最后造成劣质的代码满天飞，到处（无论哪个公司或项目）都充斥着这种随心所欲的代码

分层已经失去意义，因为整个系统在局外人看来已经只有一层，那就是业务逻辑层，上至html、下至数据库存储过程

都充满业务逻辑。联想一下，这只是用户注册而已，还有更加复杂的业务场景还没说出来。不知道最后会怎样

这样的系统已经完完全全一团面条了，后续维护已经与个人技能无关了

好了，吐槽了一下现状（不管你们同不同意，反正我是不会收回的，哈）

有没有方法解决上面这种窘境呢，当然是有的，比如我就觉得那种蓝色的方案勉强还可以

在UI层解决数据合法性校验，在逻辑层完成功能性问题，分工还算明确，这种方案对付一般的简单业务场景是足够了

但是如果业务场景足够复杂，那就不行了，因为这会造成2个明显的问题

1、UI层不够薄，这层只是调用后台的方法而已，按道理校验的事情是无需管的（我说的是cs层的校验，不是js）

    这就像去银行办业务，用户不管钱假不假（因为可能不知道），够不够（可能也不知道，比如他想存一分钱）

    这些银行员工告诉他就可以了

2、业务逻辑不能重用，比如场景1要求注册用户需要完成1-4项，场景2要求完成2-5项，场景3、场景4。。。。

    这就蛋疼了，我们要为每一个场景实现校验到存储的所有过程，代码冗余很大，到处都是相似的代码。

    但是有的开发会说，难道我不能再一个方法里边写if else switch码？那样不就可以兼容其他场景了？

    当然可以那样，但是从此以后整个项目就开始堕落，前面一拨人胡乱搞完拍拍屁股走了，

    后边接手的也只能往上边扔更多的扭纹柴了，只到开始改动一个逗号“,”，都会影响其他功能，项目已经彻底走不下去了

    那怎么办？用老板的方法：很简单嘛，项目停掉暂且用着，然后招一批新人从新开发系统，边上边用。把业务都转移到新系统上

    然后新的开发做完系统（可能还没到上线）就拍拍屁股走了，后边的接手的人。。。。然后一个循环的怪圈就开始了。。。

话题转回来，这么样解决这种窘境，比较合适的业界比较推崇的方法就是加入服务层，来看看加入服务层后的逻辑分层

2、加入服务层后的逻辑分层

如何实施呢？我的想法是，UI层只做调用的操作，在构造函数中注入service或直接在Action中调用远程服务方法就好了

当然也可以做一些比如String.IsNullOrEmpty、“value”.ToInt(1);的操作，不过这并不代表服务层就不需要做

服务层还是需要重复校验输入参数是否合法的，所以上边的操作基本没啥卵用，因为服务层从设计角度来说他是不信任任何输入的

不然单元测试都过不去，那服务层到底做些什么呢？可以大概分为以下几个方面

1、解耦UI层与业务逻辑的强耦合

2、较少业务逻辑调用次数

3、层次更加分明，代码简洁

4、部署灵活，以后做集群很方便

如果没有服务层，UI层Controller是怎么写的？大概如下：

RegisterController.cs

UserApplication.cs

如上边代码所示，Controller层太重（很多判断我没写出来，实际情况肯定没有那么简洁的），而且如果是客户端远程部署（不一定是WEB，有可能是C/S、手机等），

那性能肯定很差，因为UI层需要穿透壁垒损耗性能，而且携带大量数据远程传输，多次远程访问等等；而Application也很杂乱，

有些方法比如SendMail这个应该是属于功能性的需求，不是业务性的需求，CheckIp也是，这些不应该写在一起，因为从语义上讲，他们都应该不属于同一个地方

所以要想性能高，Business层要分2层，一层处理业务逻辑（Application），一层处理非业务逻辑（组织相关业务逻辑，即Service），

那就要改了，Controller层和应用层就不能厚，一定要薄，。。

3、加入分层后的代码分布

Controller.cs，控制器变了，直接调用WCF，原来是在构造函数中注入Application的

DTO也变了很多，加了所以注册需要用到的参数属性

我们看看WCF的实现

可以看到，分割线上是属于数据合法性校验，之下属于业务逻辑层面的校验

至于LoginUserApplication，之前我们已经实现了，是属于单元（原子）业务层面的功能，只有CRUD

4、看看界面运行效果

好了，自此，服务层功能算是介绍完毕了！