请问Repository这个概念如何理解啊
最近接手维护一个项目用到了prettus/l5-repository 这个库，里面涉及到了Repository Pattern这种设计模式，其中Repository 和 Criteria 这两个概念让我着实很费解。
主要是两方面
1、Repository感觉和DAO很像。比如Repository提供的一系列方法， getById findBy() 之类的，感觉做一个baseModel的父类继承一下也一样能实现，而且Repository这些方法本质上还是依赖于$this->model，即eloquent model来实现。不理解为什么要再划分出Repository的意义，而且Repository层还要绑定一层接口到实现，是为了便于更换数据源做单元测试之类的？
2、Criteria这个概念不知道中文用什么来表述。看上去有点像复用的条件组的概念，和 Scope 很像。
3、Fractal Presenter和 Transformer我就更搞不懂了。之前项目业务逻辑都是在service层处理的，从数据源返回数据后，通常就是根据接口输出的字段要求，循环做一些修饰和删减。有必要搞这么复杂吗？
现在这个项目代码分了这么多层，一条业务逻辑线拆的稀碎，接口到实现IDE追代码也十分不友好，写新的代码一开始要创建一大堆的文件，真是心累。
关于 LearnKu
粤公网安备 44030502004330号
平时没有用过，但谈一点我对仓库层的理解。
第一点是做数据访问的进一步抽象化，这方面可以考虑一个场景：
业务通过仓库获取数据的时候，可以不用太过关心数据来源是访问数据库、缓存还是来自接口、RPC等，这单纯用模型无法实现。即便是访问数据库，我们也可以将分库和分表条件等逻辑放到仓库层进行处理。
Criteria 我理解为对条件的抽象化。单纯使用模型的时候，很多条件也是重复的，如果被封装便是可被复用的，l5 他们将其直接和请求关联起来，这就简化了很多请求的撰写工作，前端可以直接根据他们标准的查询请求参数直接访问仓库数据。这点上比较 laravel 的 GraphQL 扩展 light-house 已经很接近其强大的查询能力了。
Presenter 我理解为对数据读写的转译，核心还是抽象化。
要不要用仓库模式的问题我的理解是：简单的问题用简单的方法解决。这些设计模式都是在控制项目开发过程中的熵增问题。