目录

repository

在项目业务逐渐庞大，业务数据进一步抽象后，很需要一个所谓的数据源repo用来提供给业务逻辑层获取或更新数据，而repo负责查询与更新数据，至于repo找哪个model实现数据查询与更新，业务逻辑层其实不要去操心和关心，只需要对接repo就可以，就像当时业务不那么庞大时，业务逻辑层会直接找各自的model实现数据的查询与更新，现在直接通过repo来解耦业务逻辑与model。

有很多人强烈建议上repository，andersao/l5-repository: Laravel 5 - Repositories to abstract the database layer也很详细介绍了repository作为数据抽象层的使用方式，这边以中文当时概要记录，方便快速浏览。

repository对model的抽象，主要做了什么

  • 通用DQL、DML封装
    • 查询
      • 获取所有记录
      • 支持id获取记录
      • 分页获取记录（建议id或索引field游标获取下一页的方式）
      • 支持指定field获取记录（建议索引）
      • 支持多条件查询（and条件）
        • 比较（支持date日期的比较）
        • in、not in
        • between
      • 支持whereIn、whereBetween、whereNotIn
      • 支持过滤隐藏敏感field
      • 支持白名单field
      • 支持model关联查询
      • limit => take
      • 支持自定scope
      • 排序sortBy
    • 插入create
    • 更新update
      • 只支持通过id更新
    • 支持updateOrCreate
    • 删除
      • 支持通过id删除
      • 支持通过更多条件删除
  • 支持标准查询条件criteria
    • request crireria（相当于repository层定义好读取解析url的规则，直接generate对应model方法并执行，类似于jqgrid+tp的model抽象层）
  • 支持cache层（比如可以开启配置，也可以在repository单独配置）
  • 支持validator验证器
  • 支持presenter输出自定义（比如格式或是filed调整等）
    • transform定义

小结

  • 支持大部分model操作，对于项目需要特殊的查询可以根据实际情况封装
  • 作为model的一个小抽象层，能提高开发效率，避免低级的sql问题
  • 验证器可以进一步控制数据的入库，但这里验证器原先的目的是担心input数据直接写入model
  • presenter中的transform可以把控数据统一输出，避免model数据随便下发给客户端。
  • 很多项目并没有真正使用到model，仍然在array或是基础object层面上操作数据集，建议充分理解model的定义的数据结构与使用方式，再推广使用
  • 其实项目没有大到需要这么高层的抽象，或者说业务数据并不需要抽象出一个数据源repo，repo去使用不同的model要数据时，大可直接使用model。

建议逐渐使用。