写了一个简单强大的 laravel 的 repository 层

[zhaohehe]

https://github.com/zhaohehe/z-repository

[ss098]

心疼，摸摸。

蛮好的，第一个给你点了星星。

[wenymedia]

之前看到一个类似的…

[jswh]

我一直不太明白 repository 层存在的意义，觉得没有必要，但是很多 ORM 都会增加这一层。可能是因为我不太喜欢 Model -> Table ，而是喜欢 Table -> Model 的模型定义过程吧。 Laravel 的也是这样的，所以他的 migration 里面提供数据库表的定义工具，并且根据这个自动生成 Model ，而不是根据 Model 来生成 Table 。失去了 Table 定义的功能，再由 Repository 来接管所有的 CURD, Model 层的功能就太单薄了，调用起来还麻烦。

Laravel 有抽象的 CURD 层，但把功能的入口点都绑在了 Model 身上，比如->query()方法，比如 collection ，或者说 Laravel 的 Model 本质是个 Repository ，省掉了 new Repository(Model) 的过程。

[jswh]

@jswh 不小心发出去了。所以我的结论是，给 Laravel 加 repository 是画蛇添足，没有必要。个人浅见，大家一起讨论

[zhaohehe]

@jswh 我觉得 model 本身已经定义了一些和表本身相关的东西，比如 relationship 之类的，有时候需要对数据库进行比较复杂的操作的时候如果再把这些操作也写在 model 里面， model 类就会变得蛮大。这个时候就有必要把对数据库的复杂操作封装好单独拿出来，比如涉及到多个关联表插入的事务。这样 model 类的职责就是单纯的映射到一个表，不提供封装好了的操作，在 repository 里面对数据库的操作除了一般是直接拿到 repository 中的 model 本身进行查询，通过改变 model 对象，来改变 model 的查询结果。这样做还有一个好处就是以后要是引入了其他类型的数据库，比如 mogodb ，就不需要在 controller 里面去修改，不去动核心的业务逻辑，去修改 repository 就好， repository 本身是被接口限制的，所以可以很好的解开耦合。
我个人觉得 repository 还有一个好处就是把查询条件和结果的 transform 也集成进来，这样可以大大减少 controller 里面的代码，让业务逻辑更加清晰，出了 bug 也可以快速将范围缩小到某一个局部。

[zhaohehe]

@ss098 谢谢 😆