l5-repository，请教一下这个的实用性

能讲解一下这几个文件都是干什么用的吗
Models，Validators，controllers 知道别的不是很清楚

@lx1036 这东西受教了，解决了我多年的疑惑，谢谢

@lx1036
厉害，这东西真的重要。

我在别处的一个回答 直接粘贴过来：

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

https://github.com/zhaohehe/z-repository 这是我之前写的一个小型的repository包，借鉴了不少l5-repository的思想。

@zhaohehe 嗯好的，谢谢回来看一下那个包说明

@lx1036 这个文章太棒了

repository 接口层感觉是没有存在必要的, 只会加重设计. 因为在一般情况下,切换数据库的几率非常非常低

http://www.sangeng.org/blog/detail_517.htm... 简体中文版可能更舒服些

选择l5-repository，但是不能在eloquent文件中用where方法，好像只能用其封装好的那些方法，如果有一些更特殊的需求，它的方法不能完全满足。请问该怎么扩展这里？用DB？

解耦 重构简单，应对变化的需求很重要，虽然多了几个文件，多了几个调。如果项目的需求有极大的可能发生变化，不需要每个文件都重构，这就看你接口设计的水平了