关于项目中 Repository 层的思考

前言

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

Repository 的定位

我理解 Repository 是个大仓库,里面可以有 MySQLRedisMongoDB … 等数据。

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

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

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

Repository 的实现

  • 可配置条件查询
  • 可配置数据转换
  • 可配置数据验证

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

如果你使用的是 Laravel 框架,可以参考下 andersao/l5-repository

Repository 的接口

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

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

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

小结

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

列举一些优点:

  • 更换、升级 ORM 引擎时,不影响业务逻辑;
  • 便于单元测试,可用 Mock 对象代替实际的数据库存取;

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

推荐阅读

本作品采用《CC 协议》,转载必须注明作者和本文链接
日拱一卒
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 5

看项目大小跟架构了,小项目没必要过度设计了,大起来后个人觉得还是需要的

1周前 评论

目前正在用,缺点就是如果不是 8.0 在导致构造方法注入过多。唯一的办法就是拆分但是这样又导致了其他程度的耦合

1周前 评论

个人观点,还需要在数据仓库层加一个service层,去调度不同的数据仓库,实现复杂的跨仓库查询,然后返回给调用的控制器。如果还需要细分,那可以在service层之上再有一层Interface层,Interface→service实现Interface(这样有利于管理,也可以不加)并且通过注入的方式调用repository。repository符合单一原则调用单一的模型(UserRepository调用User模型,OderListRepository调用OderList模型)进行不同条件查询。
最后控制器根据需要,调用不用的service,复杂的业务逻辑在service中通过调用不同的数据仓库实现。

1周前 评论
xinliang (楼主) 1周前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!