60 lines
2.0 KiB
Markdown
60 lines
2.0 KiB
Markdown
|
## 服务
|
|||
|
|
|
|||
|
|
目前除了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调用
|
|||
|
|
|
|||
|
|
```php
|
|||
|
|
|
|||
|
|
//通过make 调用 TaskService 触发任务
|
|||
|
|
make(TaskService::class)->triggerTaskInner([
|
|||
|
|
'task_key' => $task,
|
|||
|
|
'options' => [
|
|||
|
|
'member_id' => $member_id
|
|||
|
|
]
|
|||
|
|
]);
|
|||
|
|
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 通过services() 函数调用
|
|||
|
|
|
|||
|
|
```php
|
|||
|
|
|
|||
|
|
// 通过services() 调用MemberSaveService 执行checkMember
|
|||
|
|
public function add(array $data): array
|
|||
|
|
{
|
|||
|
|
//
|
|||
|
|
/**
|
|||
|
|
* @var MemberSaveService $service
|
|||
|
|
*/
|
|||
|
|
$service = services(MemberSaveService::class);
|
|||
|
|
$this->checkMember($data);
|
|||
|
|
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 为什么不建议使用容器获取或注解？
|
|||
|
|
使用Di或注解虽然可以高并发提供内存占用以及免去class 重复创建性能损耗，但容器或注解会使依赖对象变为单列，对象均不能包含状态值。因此破坏了oop 部分设计模式的拓展和应用，反而是限制了服务或对象的拓展以及延申。对于业务逻辑代码每次跟随请求变化，短生命周期更容易开发&维护。
|
|||
|
|
|
|||
|
|
如果某些场景需要长生命周期，应使用协程上下文来保存依赖对象或数据。
|