个人觉得这和 ORM 与否没什么关系，不是 Eloquent 才会出现的疑惑，更和面向对象没关系，因为我们的开发，早已经假设一切问题都建立在 oop 之上。并不是说 this.id 就是 oop ， oop 更多的是一种思考问题的方式。

我们从思考问题的方式出发。

首先还得看业务需求，如果 User 是一个模块 /领域模型 /聚集的根（主入口，唯一标识），那么它内部所维护的各个值对象理应通过 User 来拿，我们姑且以模块来称呼这个 User 的功能，如果 User 这个模块的一个重要功能是按照特定的 User 实体去获得属于他的 /关联的其它对象，我想不出为什么不直接写在 User 数据库类中，因为，特定的用户不存在的时候，与他相关的一切其它值都将失去意义。 Laravel ORM 把对象关系映射、实体、模块聚集浓缩到了一层中，直接去在 User 对象中访问模块内部的其它元素便是了。然后你可能因为测试 /关注分离 /业务和基础设施分离等原因，可能会在客户端代码和 User 对象中增加类似 Repository 、 Factory 之类的东西，这个时候 Factory 返回的将是一个 User 模块的聚集，它的根是 User 对象，它的其它元素，就是你自己维护的与 User 对象相关的其它实体。

尽管这样我也见过有人用另一种方式，也就是使用动态的数据库查询去返回对象（楼主的方法 2 ），这么做的目的是给 User 模块瘦身，但是我个人偏好第一种。第一种方式拿 User 的关联元素， 维护时可能仅仅需要修改特定类的方法，第二种则要修改分散到系统各处的条件，甚至更复杂些，有人用对象表示查询条件。

写的挺好的， 只是目前以大写开头的文件名一般都是类，所以 .class.php 的写法建议换一换，有四五年没见过这种写法了，实话说还是很不习惯。

本来就可以直接 Class::$property ， 还要什么 setter 阿：）

这个和应用的执行流程关系不大的。

主要就像楼上的高手说的， 1 ， 方便替换具体实现， 2 ，依赖于能力，而不是身份， 3 ， 方便测试， 4 ，稍微一丁点提高编码效率。

你讲的是一个 app 常用的执行过程， 但是在一个中等规模的 app 中，这些流程只是基础设施， 你的业务代码会非常的多，对象之间的依赖会非常复杂，依赖注入能够让你开发速度更快， 修改具体实现的时候无需触碰业务代码。

new Service() 也是一种依赖注入，只不过是你手写的，而且无法注入接口，依赖注入更加灵活。

还是沈阳的呢，我也会 Laravel ，有需要可以联系， 个人资料里有 Github ， Github 资料里有 QQ 。
哈哈，我只是很开心看到一个沈阳的。

比较聪明的做法，卖了自己用的，换两个稍微低端些的哦。这样一个自己用，一个开发多好。

id 建索引， category 移除， limit 改小，用 id 做细节限制。

@bullettrain1433 666 投赞成票！

@lianghudou 小弟不才，想看看哥哥“逻辑没被摧毁，思维清晰”的代码学习下可以么？ （可以是任意语言）

其它的都是程序自动 throw 的。

@tabris17 如果你对轻量的定义就是是否能最大限度的利用计算机资源，那我们没在一个层次上讨论问题。 PHP 自然有他独特的适用场景，我们的讨论都是建立在这个场景之上（你要去使用），而不是深挖坟的说哇我不会横向扩容哦。

10 年前的“优化指南”了。引擎升级无数次了都。

@ChenKe 这就是不同数据类型的使用问题， 其实理应你自己理顺的。
为了更好的兼容性，建议你在模版中以数组方式输出。 因为即使是对象基本都实现了 ArrayAccess 接口， Eloquent 支持数组语法访问。

这个年代还有看源码体积决定是否使用的， 内存才多少钱：）
至于是否过度设计，看需求喽， Laravel 好在可以适合各种规模的设计。

没提供任何有价值的信息。

我都提交好几次反馈了， 根本不给开。

微服务架构哦，不错呦。