关于项目中 Repository 层的思考

文章目录：

• 前言

• Repository 的定位

• Repository 的实现

• Repository 的接口

• 小结

• 推荐阅读

前言

关于项目中是否需要 Repository 层？这个问题，好像没有肯定的答案，下面是我的思考分享给大家，不喜勿喷。

Repository 的定位

我理解 Repository 是个大仓库，里面可以有 MySQL、Redis、MongoDB ... 等数据。

维护这一层的开发者，可以称为 仓库管理员 ，当使用者需要查询数据的时候，需要告诉仓库管理员，由仓库管理员拿给他，至于仓库管理员从哪拿的数据，使用者无需关系。

同理，当需要创建或更新数据的时候，也需要告诉仓库管理员，由仓库管理员进行操作数据。

总结：Repository 主要是封装数据的查询、创建、更新、删除等逻辑，供使用者调用。

Repository 的实现

• 可配置条件查询

• 可配置数据转换

• 可配置数据验证

解释下 “可配置数据转换” ：当我们需要返回隐私性字段时，例：如手机号，如果使用者无数据权限时，手机号字段中间 4 位需要进行加 * 处理，还有处理返回的时间格式等。

如果你使用的是 Laravel 框架，可以参考下 andersao/l5-repository^[1]

Repository 的接口

Repository 层的接口可以理解为契约（可了解下 Laravel Contracts 目录），它是受 Domain 驱动的，Repository 中定义的功能要体现 Domain 的意图和约束。Domain 需要什么我才提供什么，不需要的我不会提供。

例如，接口名可以定义为 searchUsersById 、searchUsersByName，不可以定义为 searchUsersByInfo，查询的字段也不建议设置为 * ，仅查询需要的字段进行返回。

什么是 Domain？可以理解为领域层。

小结

使用 Repository 层有利有弊，弊端就是有些繁琐，没有 ORM 一把梭的顺畅。当然优点也有很多，主要是后期的可维护性大大提高。

列举一些优点：

• 更换、升级 ORM 引擎时，不影响业务逻辑；

• 便于单元测试，可用 Mock 对象代替实际的数据库存取；

以上，希望对你能够有所帮助。

推荐阅读

• 你知道什么是 AOP 吗？

• 编程是一种思想，而不是敲代码

• 做业务系统研发如何做到认真负责？

参考资料

[1]

andersao/l5-repository: https://github.com/andersao/l5-repository