|
|
4 月之前 | |
|---|---|---|
| .. | ||
| activity | 5 月之前 | |
| agent | 6 月之前 | |
| article | 7 月之前 | |
| diy | 6 月之前 | |
| kefu | 7 月之前 | |
| message | 7 月之前 | |
| order | 6 月之前 | |
| other | 6 月之前 | |
| out | 1 年之前 | |
| pay | 6 月之前 | |
| pc | 7 月之前 | |
| product | 5 月之前 | |
| serve | 1 年之前 | |
| shipping | 6 月之前 | |
| statistic | 1 年之前 | |
| system | 6 月之前 | |
| user | 4 月之前 | |
| 4 月之前 | ||
| yihaotong | 2 年之前 | |
| BaseServices.php | 11 月之前 | |
| README.md | 1 年之前 | |
| filetree.txt | 3 年之前 | |
crmeb/app/services目录用于定义项目的业务服务类。
服务类的主要特征和作用包括:
服务类封装具体的业务逻辑和规则。
完成功能模块的抽象,提供统一的业务接口。
解耦项目各部分,降低他们之间的耦合度。
提供给上下文的整个环境使用。
具体来说:
每个服务类对应一个独立的业务功能或规则集合。
类内部可以调用其它模块完成业务需求。
对外提供简单的业务接口,隐藏内部实现细节。
服务类存在依赖关系,可以互相调用实现聚合服务。
使用服务层设计可以:
松耦合各个模块,提高扩展和重用能力。
同一个业务规则在多个场景复用。
加强项目的可测试性与维护性。
所以此目录定义了项目核心业务服务模块,对外提供可复用的核心能力。