Laravel Repositories

在laravel中Repositories存在的好处是什么，在laravel4中存在着这个文件夹，在5中将这个删除掉了，然而我感觉这个的存在使应用的整个业务逻辑在model层方面展现的更为抽象，感觉是为了一点的好处使程序的请求饶了一圈，可能是我的水平还达不到能够理解其存在的思想所在，谁能阐述下其存在的优点和好处以及为什么存在？有没有必要在laravel5.中继续使用吗？

回复内容：

在laravel中Repositories存在的好处是什么，在laravel4中存在着这个文件夹，在5中将这个删除掉了，然而我感觉这个的存在使应用的整个业务逻辑在model层方面展现的更为抽象，感觉是为了一点的好处使程序的请求饶了一圈，可能是我的水平还达不到能够理解其存在的思想所在，谁能阐述下其存在的优点和好处以及为什么存在？有没有必要在laravel5.中继续使用吗？

不止在PHP,在JAVA,.NET等都有使用这样的设计。

补充下自己的使用场景：

1. 在 Repositories 中封装通用的分页模块。

2. 通过依赖注入，实例化Model对象。

3. 在 Repositories 实现复杂查询，返回controller需要的数据。

4. Model 基本用来映射对应的表，做主外键级联更新。指定Presenter类。

在Controller 中只会对Repositories 进行调用。

自己在网上找了一篇关于这方面的文章，翻译了下，翻译的不太好。有需要的可以参考下http://segmentfault.com/a/1190000003488038?_ea=317641

• 是不是还是该加上Repositories？

• 我最近刚学laravel不久，我发现直接在Controller里面使用数据库的操作很不好，正在找解决方案，在一个代码里发现有用Repositories，然后在laravel5.1里面已经不存在这个文件夹了，是不是还是该自己建起来，或者怎么实现数据库操作和控制器中逻辑的分离。

@ideading 你们所说的是设计模式中的 repository pattern，属于各个面向对象语言通用的实践。
Laravel 4 的时候是为了方便用户写出更好的代码，所以设计的比较拖沓。如果你觉得自己有必要继续这样，自己建类。

Taylor Otwell 一直在根据自己的代码经验对 Laravel/Laravel 这个库（也就是 Laravel 应用的默认骨架）做调整，比如从 5.0 到 5.1，为了不让用户产生错觉，把 Command 目录重命名为 Jobs，突出 Command 最佳使用场景是 Queue，因为之前大量的人用这个目录去盛放 command pattern 的内容。 Taylor 在自己的产品 Forge 中尝试使用这种设计模式的事后发现，会导致大量的重复工作，原话是 1900 个类，他觉得绝大多数产品都不需要这种模式，在控制器中处理就好。

Laravel 是一个吸收很多语言实践的框架，理解其中内容的时候，建议脱离 Laravel 甚至脱离 PHP 本身去理解。