Laravel Repositories

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

阅读 6.5k
5 个回答

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

补充下自己的使用场景:

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

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

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

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

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

可以说,在任何正式的、大型的、严肃的laravel项目中,不用repository pattern是难以想象的,也即不规范的。使用repository来分离你的controller与数据操作逻辑,应该是你laravel学习的第一课,也即入门阶段就要加以理解和尝试应用
具体的,可以看看我的laravel入门课程:
Laravel实战:任务管理系统

repository pattern可谓也是laravel设计的一个核心,其背后所涉及到的依赖解析、服务解耦、面向interface的团队开发流程、或者说面向contracts的理念,是我们真正用好laravel,包括理解其他任何优秀框架的核心,也正是基于这些考虑,所以在我这个入门课程就以简单的方式推荐大家使用repository了

当然这里还有一篇更深入一些的文章
"修饰"(Decorate)Laravel里面的Repositories

当然,更进一步地,想一起来研读laravel源码的,一步步理解laravel如何实现框架自身的,可以一起来关注我的高级课程:
Laravel底层核心技术实战揭秘

  • 是不是还是该加上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 本身去理解。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
宣传栏