Laravel&Lumen系统之服务剥离

最近随着业务的不断发展,越来越复杂的逻辑交织在一起使得原来的代码很难维护,同一个类似的逻辑在多个地方调用,每次逻辑变更的时候非常容易忘记改其中的一处地方。所以需要抽出一个服务层来处理业务。

在app目录下单独创建了service文件夹来存放所有的服务。根据大的业务又分成了不同的子文件夹,针对每个大模块创建对应的工厂类,以便于后期调用的时候能够方便调用,不需要到不同文件夹找对应的类名。

随意找其中的一个例子来叙述下,比如说订单的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中就可以类似于这么写,这样所有地方都可以复用,实现代码封装。

Laravel&Lumen系统之服务剥离》上有2条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注