member-doc/quick-dev/service.md

服务

目前除了RiskControl层外所有的新建服务必须继承 BaseService 并且实现 LogicServiceContract 接口，即app/Service/RiskControl 下文件除外。

这样继承之后新的服务就会自动依赖ApiConfigService数据，并且提供setData($data),setId($id)自定义依赖数据源。

开发者在任何一个服务类中$this->data 获取前端或外部输入数据。

创建公共服务

在app/Service/Common 新建公共服务文件

创建逻辑服务

在app/Service/LogicModule 新建服务文件。

1. 建议开发者新建逻辑服务，应该考虑功能模块划分，将复杂功能拆分若干细小的模块，减少模块之间耦合性。
2. 建议开发者处理好interface与class 实现类的关系，它们之间应该是一对多关系，interface属于高级别约束，而非实现类方法定义集合。

服务之间调用

通过make调用

    //通过make 调用 TaskService 触发任务
    make(TaskService::class)->triggerTaskInner([
        'task_key' => $task,
        'options'  => [
            'member_id' => $member_id
        ]
    ]);
   

通过services() 函数调用

    // 通过services() 调用MemberSaveService 执行checkMember
    public function add(array $data): array
    {
        //
        /**
         * @var MemberSaveService $service
         */
        $service = services(MemberSaveService::class);
        $this->checkMember($data);

    }

为什么不建议使用容器获取或注解？

使用Di或注解虽然可以高并发提供内存占用以及免去class 重复创建性能损耗，但容器或注解会使依赖对象变为单列，对象均不能包含状态值。因此破坏了oop 部分设计模式的拓展和应用，反而是限制了服务或对象的拓展以及延申。对于业务逻辑代码每次跟随请求变化，短生命周期更容易开发&维护。

如果某些场景需要长生命周期，应使用协程上下文来保存依赖对象或数据。