最近随着业务的不断发展，越来越复杂的逻辑交织在一起使得原来的代码很难维护，同一个类似的逻辑在多个地方调用，每次逻辑变更的时候非常容易忘记改其中的一处地方。所以需要抽出一个服务层来处理业务。
在app目录下单独创建了service文件夹来存放所有的服务。根据大的业务又分成了不同的子文件夹，针对每个大模块创建对应的工厂类，以便于后期调用的时候能够方便调用，不需要到不同文件夹找对应的类名。
Paste_Image.png
随意找其中的一个例子来叙述下，比如说订单的OrderService.php:
class OrderService
{
/**
* 录入订单
* @param $obj
* @return bool
*/
public function add($obj)
{
******
}
/**
* 获取某一个订单对象
* @param $id
* return mixed
*/
public function getById($id)
{
******
}
/**
* 获取某一个订单对象
* @param $orderSn
* return mixed
*/
public function getByOrderSn($orderSn)
{
******
}
/**
* 获取订单数组
* @param $idArr [3,4,5]
* @return mixed
*/
public function getArrByIdArr($idArr)
{
******
}
/**
* 更新订单状态
* @param $id
* @param $state
* $return void
*/
public function updateState($id, $state)
{
******
}
这里是订单相关最基础的几个服务，订单服务类提供的服务基本满足几个条件，尽量原子化，粒度尽量小，这样能够更好的解耦，当然强数据一致性的功能可以放在一起。比如更新订单状态这个功能，可以同时更新订单明细的状态耦合在一起，因为这是非常强数据相关的功能。
这样在原来的Controller里面只需要调用Service层的服务即可，不需要直接使用Model操作数据库，这样的好处就是功能复用，以及避免复杂Sql大家写错，因为Laravel&Lumen框架的Orm是比较强大的，非常容易写错。考虑到一些业务层面的服务提供，对于每个模块又有一个Trait，把一些可复用的业务功能合并在一个方法中，这样在不同的地方都可以共同调用。同时在未来业务更改的时候，只需要修改Trait中对应的方法即可，代码维护性非常高。
trait ShipStatic
{
public function orderShip($order, $express, $expresses, $expressNumber)
{
// 获取当前所有需要的服务
******
// 录入第一条必填快递信息
******
// 录入后面可选快递信息
******
// 计算订单自动收获时间
******
// 更新订单
******
// 更新订单明细
******
// 更新流水
******
// 通知用户信息
******
}
}
Trait中就可以类似于这么写，这样所有地方都可以复用，实现代码封装。
大家喜欢可以访问我的个人网站：http://www.yingminxing.com
如有疑问，欢迎沟通交流：QQ:370399195, 微信:yingminxing1988
