请问Repository这个概念如何理解啊

平时没有用过，但谈一点我对仓库层的理解。

第一点是做数据访问的进一步抽象化，这方面可以考虑一个场景：

业务通过仓库获取数据的时候，可以不用太过关心数据来源是访问数据库、缓存还是来自接口、RPC等，这单纯用模型无法实现。即便是访问数据库，我们也可以将分库和分表条件等逻辑放到仓库层进行处理。

Criteria 我理解为对条件的抽象化。单纯使用模型的时候，很多条件也是重复的，如果被封装便是可被复用的，l5 他们将其直接和请求关联起来，这就简化了很多请求的撰写工作，前端可以直接根据他们标准的查询请求参数直接访问仓库数据。这点上比较 laravel 的 GraphQL 扩展 light-house 已经很接近其强大的查询能力了。

Presenter 我理解为对数据读写的转译，核心还是抽象化。

要不要用仓库模式的问题我的理解是：简单的问题用简单的方法解决。这些设计模式都是在控制项目开发过程中的熵增问题。

只用过 Repository，说说我的理解，不确定够不够准确。场景是后台一套 API, 小程序一套 API，web 前台使用 blade 模板。 三端获取文章列表有一些共用的约束条件，如果直接使用 Eloquent ，将来如有修改需要改三个地方，一来比较麻烦，二来可能会忘了改动某处。三端共用一个 Repository 后，一来修改省事，二来能保持一致性。

大佬曾经说过：“Algorithms + Data Structures = Programs”。

作为crud的业务仔的我，是这样理解的：存取数据（dao）+业务逻辑(service)=程序。

其实这些都是抽象 都是基于项目设计的抽象 比如你要做一个用户管理的模块 包括用户的增删改查等操作 但你先不写实现 先抛开实现写抽象 抽象不依赖任何东西 只要定义好输入和输出 符合你的需求就可以了
然后你再考虑对抽象的实现 比如你们现在数据是基于Mysql的存储 那你就可以写一个对这个抽象类mysql版的实现 如果哪天你们换实现了, 可能觉得mysql太慢了换redis或者直接接第三方了， 你就可以对这个抽象类写一个另外的实现 简单来说 抽象不依赖于实现 业务不改变的情况下 抽象的实现类是可以多种多样并且快速根据具体情况去切换的 业务改变的情况下 也是一样的 先去对抽象类进行修改 然后再修改对应实现类 Repository你也可以这么理解 可能有个UserRepositoryInterface 这个用户仓库抽象类不依赖任何服务 对UserRepositoryInterface的实现类才会在实例化的时候注入对应的依赖服务