当前位置：首页 > news >正文

Laravel / Lumen 实践总结

news 来源：原创 2024/4/28 18:19:24

2019独角兽企业重金招聘Python工程师标准>>>

不要造轮子

业务推进不应该耗在轮子制造上

典型、常见的功能首先考虑Laravel框架是否已有实现，其次搜索开源的轮子
Composer兴起：PHP进入现代化开发阶段、大家可以共享优秀的轮子
使用现成的轮子
- 框架内置的轮子：适度定制满足业务，以后框架升级最为方便
- 大牛开源的轮子：功能丰富、架构规范、拓展性强、文档完善、持续维护！！

现成轮子不满足部分需求或有Bug？

不要直接修改！！vendor目录下框架内部组件或第三方包
- 造成包无法进行后续更新
- Compser重装vendor包后，定制修改将会丢失
新建逻辑分层进行定制（比如Libraries目录）
1. 目录结构组织参照vendor下的原始实现类
2. extends原始实现类覆盖需要定制的方法，或者直接implements其整个Constract约定
3. 在业务逻辑中（而不是vendor目录）替换为自定义类

几个轮子参考站点

Laravel专属包搜索：http://packalyst.com
Composer官方搜索：https://packagist.org
Github搜索：https://github.com
Laravel一些开源项目：http://openlaravel.com
Spatie开源的Laravel项目：https://spatie.be/en/opensource/laravel
PHP优秀包联盟：http://thephpleague.com

Laravel主流分层思想

系统架构需要逻辑分层，每个分层遵循单一职责原则主流分层

Web分层

Controller层作为业务逻辑的总调度，可注入Service、Repository等
Service层辅助Controller层，抽象复杂业务逻辑、抽象公共服务、处理第三方功能调用等
Repository层具体处理CURD的SQL业务、第三方数据调用等资源操作逻辑，可注入Model
- 需要面向接口开发，依照接口声明处理 DB、Cache、Api等实现
Model层作为业务实体，处理常量定义、关联关系、配置定义
View层处理视图展现

Api分层

1. 业务：Dingo路由 + Controller调度 + Service业务逻辑 -> Transformer数据修饰输出

2. 数据逻辑：Query过滤参数&Repository查询 + Hydrator数据校验并存储 -> Policy鉴权策略

3. 数据：Model（域、常量、关联） + Migration、Factory、Seeder

4. 配置：Config配置 > ENV环境变量

*. 其它：Test（状态码、数据结构、过滤条件）

Laraval权限分层

1. 顶层基于Auth中间件的用户身份认证
2. 主体**基于角色**的RBAC权限架构设计
  - 基于角色分类组织权限节点
  - 决定某个角色能使用什么功能、能做什么操作
3. 底层**基于用户**的鉴权
  * 基于Gate的资源无关操作鉴权
    - 鉴权用户能否某种操作，一般与资源实例无关
    - 定义了单一权限节点的鉴权逻辑
  * 基于Policy的Model实例资源鉴权
    - 鉴权用户能否对Model实例资源进行某种操作
    - 封装资源的多个权限节点鉴权逻辑于一个策略中，并与Model绑定

错误和异常处理

使用异常的好处

不用针对正常、错误的返回而使用类似[status=>sucees, data => $data]这种结构
业务中引入异常体系后，逻辑更加语义化

异常处理原则

业务设计之内的异常，自己抛出自己捕获处理
- 正常场景就返回数据，错误场景就抛出异常
- 抛出的异常在外层业务进行捕获并进一步处理
业务设计以外的异常，自己未能捕获，冒泡至Handler顶层异常处理器处理
异常基类
- 需要显示的异常继承自\Symfony\Component\HttpKernel\Exception\HttpException
- 业务逻辑中组织的异常继承自\Exception、\RuntimeException等

错误日志系统

典型的报错日志系统（有缺陷）
- 日志源抓取 Laravel StorageLog、PHP error.log、Nginx error.log
- 只提供错误点的调用栈信息
- 缺少当时场景的关键信息，调试排错困难
使用Laravel的顶层异常处理器衔接报错日志系统（推荐）
- PHP7下所有Error和Exception都是Throwalbe接口的实现，均可被Catch
- report()方法中进行异常上报可实现当时场景的关键上下文信息串联，提高排查效率
  - 当时的用户对象
  - 当时完整的用户请求数据
  - 当时的异常堆栈信息

依赖注入

自动依赖注入 常用于容器自动注入空Model实体对象、业务逻辑模块等

构造函数注入：public function __construct(User $user)
接口注入
- 控制器方法中：public function index(Request $request)
- 队列Job的handle()方法中：public function handle(MailService $mailService)
- 等等

手工依赖注入 常用于手工注入具化Model实体对象、同接口下不同的业务模块实现等

Set注入：public function setUser(User $user);

使用场景区别举例
Repository层的工作依赖于Model实体，不同场景下使用不同的注入方式

查询场景下 - 自动依赖注入
- 通过构造函数来注入空Model实体
- 通过空Model实体发起newQuery进行查询
更新场景下 - 手工依赖注入

通过Setter来注入具化Model实体或id到Repository
注入的具化Model实体将作为数据更新目标

集成测试

即便做不到TDD，至少粗粒度上的集成测试来保证接口可用性，避免人工测试的困难
核心逻辑模块可以考虑更细粒度的单元测试

1. 指定测试方法 `phpunit --filter clsTest::testMethod`
2. 测试临时忽略指定检查，添加注解 @SupressWarnings("规则名")  
3. 测试覆盖范围
    - 常规场景数据返回： 数据 & 结构 & 状态码
    - 异常场景数据返回：数据不存在
    - 所有过滤字段
    - 分页功能：指定分页 & 单页条数
    - 数据录入 & 更新 正常