Laravel 作者 Taylor Otwell 主张胖模型 / 瘦控制器

Laravel

我正在收听 Taylor Otwell Laravel Snippet 第 11 集，他谈到了关于您应该将代码放在何处的辩论（应该将业务逻辑放在控制器，模型或服务）。这就是他说的：

下面我只引用 Taylor 的原话，然后提供一些评论和其他链接。那么，“瘦”或“胖”模型呢？ Laravel 的创始人更喜欢哪种方法？

我倾向于使用“胖”模型方法。我发现我的控制器实际上很瘦。

我认为 DHH (David Heinemeier Hansson) Ruby on Rails 的创始人，在多年前发表了一篇博文，内容涉及他喜欢只在 Controller 上使用 resource 相关动词。他不喜欢任何其他动作。因此，当您拥有一个 Controller 时，您只能将自己限制为只允许有以下动作 index/show/store/update/delete，并且如果您需要任何其他 action，通常这是一个提示，提示着你应考虑将这些其他动作提取到另一个资源控制器中。

所以我非常严格地遵循这一点，我发现，这使得我的控制器非常瘦，然后我会有非常肥胖的模型，其中包含非常丰富的逻辑。

我认为这种方法的一个误解是，仅仅因为模型 API 中公开了相当多的逻辑，这并不意味着执行这些任务的所有代码都必须在模型内。

以 Forge 为例，假设有一个 Site 模型具有 deploy() 方法。对于初学者来说，在 Site 模型中包含整个部署逻辑，可能不是一个好主意，因为此方法会包含相当多的业务逻辑。但是，你可以做的是，在 Site 模型上仍然有 deploy() 公共方法，但是让它调用另一个服务，或者触发一些命令或队列作业，来实际执行任务。

所以，模型在代码行方面不一定是“胖”的，但它包含丰富的公共方法 API，且保有流畅和高可读性。

但从 Taylor 的观点来看，我更喜欢的是 在模型中拥有自定义方法。很长一段时间以来，社区一直存在争论，即 Eloquent 模型只需要有 Eloquent 相关的东西，比如 $table 或 $fillables 设置、Relationships 方法、Accessors/Mutators 等，仅此而已。
但是，如果框架的创建者本人说只要它不包含所有逻辑，你就可以在其中放置任何想要的东西，我同意它比直接从 Controller 调用 Service/Job 更具有可读性。

你觉得呢？同意 Taylor 吗？你的控制器和模型有多“瘦”呢？

你可以在此收听原版的播客 Laravel Snippet 第 11 集，话题大约在 6:20 分钟开始。