探讨phpyaf框架扩展实践四——业务层

和常见的mvc框架不同，这里多了一个业务层用来封装系统业务。为什么要多一个层出来呢？以往的时候没有这个层，通常都把业务放在控制器层进行处理。在长期的开发app的数据接口中，发现控制器层做的事情实在是太多了，既要处理表单的验证、还要检测接口版本、还要处理业务。如果业务简单些还好，要是业务比较复杂，这个代码是惨不忍睹啊，维护起来也非常痛苦。

于是呢就考虑将业务层的的代码封装出来独立处理，这样就有了业务层。业务层的代码存放目录：application/models/Business/，有一个抽象类abstract.php，其中也没有什么代码就一个禁止clone的方法。这里更多的是分享一下关于业务层代码封装的思想。主要是包含以下三个：

• 目录规划
• 业务错误流程处理
• 错误码统一管理

yaf扩展业务层

目录规划

目录规划如果没有规划好，随着业务的增加，还要考虑适应旧版APP，目录就会越来越复杂。在长期的开发过程总结出了一些规律，建议目录以如下方式进行组织 ：

Business/功能模块/具体业务+版本号.php

其中功能模块就是指大的一个业务模块；具体业务就是指其中的一个业务操作；版本号就是对应业务操作的版本。如果用户登录业务就可以是这样：

一开始版本用： Business/User/Login.php
 V2版本： Business/User/LoginV2.php
 V3版本： Business/User/LoginV3.php
 ...

在项目前期因为对产品不熟悉，修改业务是常有的事情，为了兼容旧的app版本，就会考虑增加一个业务版本。这样就会导致一个业务操作版本越来越多，对维护会造成困难。这里建议对旧的业务版本进行清理，随着用户逐渐更新到新版app，旧版本的使用用户已经没有的时候就可以删除旧的业务版本了。

业务错误流程处理

首先先定义一下什么是业务错误：就是一个业务操作如果最终没有达成，中间一些条件判断没有通过返回的错误，和程序上的错误是不同的。例如在登录操作中，需要校验用户是否存在，用户如果存在还需要校验账号密码是否匹配。中间只有有一个校验没有通过就可以认为该业务发操作生了错误。

对于这样的业务错误流程怎么样处理比较好呢？

早先的时候想着直接返回错误信息：

不幸的是这样还是碰到了问题，有时候业务特别复杂的时候，通常会将其拆分成多个函数进行处理。每个函数都可能会有一些校验，每个校验如果都这样返回信息，那调用这些函数的主业务函数内不就要判断每个函数的返回结果，岂不是太麻烦了。

后来就想到使用异常的方式来中断流程，如：

这样当发生业务错误的时候就会直接中断，并且返回了错误信息和错误编码，在控制器层调用业务方法的时候捕获异常就可以了，这种方法在代码深层嵌套的时候特别有用，能有效减少编码量提高代码的可读性。

当然在每个操作action方法中捕获异常看起来还不是很简洁，庆幸的是yaf提供了异常捕获的控制器，在controllers目录下新建Error控制器并且实现errorAction方法，则应用内没有捕获的异常都会抛到这里，在这里就可以对应用内抛出的异常进行相应的处理。

错误码统一管理

上面解决了业务错误流程的处理，再把错误码统一进行管理就比较完美了，请参考项目下的application/models/Error目录，其中有一个Error类专门用来抛出异常；CodeConfig用来管理所有的错误码。代码上都比较易读就不多做说明了。

业务层的说明到这里就告一段落了，下面一篇将说明一下数据层的的封装，这个也是其中最重要的一篇了。很多项目到后面瓶颈都会在数据上，处理好了数据层项目就可以算是成功一半了。