Laravel 作者 Taylor Otwell 主张胖模型 / 瘦控制器
我正在收听 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 分钟开始。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
我比较习惯
service
这种方案,model
就应该只保留eloquent
相关的方法和属性@hldh214 +1