Laravel : 使用动作类整理你的代码（翻译）

2018-06-05 本文已影响0人阪本先生

友偶阅网文一篇，头中尾英，阅不能，遂中译之。原文链接：Keeping your Laravel applications DRY with single action classes

“这段代码该放在哪里？”恐怕是在谈论应用结构时最经常提起的问题。“我应该放在 Controller 里吗？还是 Model ？还是哪里？”，虽然 Laravel 是个十分灵活的框架，但要解答这个问题也不总能简单明了。

当你知道你的应用程序只有一个接入点的时候，把逻辑写在 Controller 是完全没问题的。但如今应用一般都会有好几个接入点共用同一个功能。

例如，很多应用都会有一个用户注册的表单，提交到 Controller ，然后根据是否成功注册来返回有用的信息。在移动端应用的场景下，一般都会有个使用 JSON 格式返回的 API 专门用于用户注册。而且利用 Laravel 的 artisan 命令来创建用户也很常见，尤其是在项目前期的开发阶段。

这些重复代码的确看上去没什么毛病，但如果就这样让业务逻辑继续扩充下去，例如：你希望给新注册用户发一封提醒邮件，那么你需要在两个 Controller 里同时加上这个逻辑。所以为了代码能够整洁优雅起来，我们需要把它放到其他地方去。

别把服务类神化了

一开始，可以先临时创建一个类，把所有针对某个业务逻辑的代码整理起来，例如：

这样看上去就好多了；我们可以直接从 Controller 里调用 User 的 create()/ delete() ，通过任意途径返回结果。然而这方式有个问题：我们处理业务逻辑的时候很少使用一种模式。

例如我们有这个业务逻辑：当用户创建账号的时候，需要创建一篇新的博客。如果我们继续使用刚才的模式，我们需要创建 BlogService 然后使其作为依赖注入到 UserService 中：

很显然，当我们的应用变得越来越大，会有越来越多的服务类，有些还依赖了 5 个甚至 6 个其他的服务类，代码像被猫玩过的毛线球剪不断理还乱 —— 我们无论如何都要避免这种结局。

如果我们不使用里面塞了几个方法的单一服务类，而是把逻辑切分到好几个类里面呢？我在最近的好几个工程里都使用了这种模式，结果十分不错。

首先，我们暂时先把“服务”这个抽象而且模糊的术语丢掉，然后引入“动作”类，并且赋予以下定义：

一个动作类，它的名字应该要能够让人一眼看出它是干什么的，例如：CreateOrder, ConfirmCheckout, DeleteProduct, AddProductToCart,…..
动作类应该只拥有一个公开接口（API）。理想情况下应该用统一的名字，例如 handle(), execute() 这样，方便我们需要在动作上实现一些模式，例如适配器。
动作类不应该关心 Request 和 Response。动作类不处理任何 Request，也不产生任何 Response，因为这是 Controller 的责任。
动作类可以依赖其他的动作。
当处理业务逻辑的时候，遇到不能返回期望内容的情况下，必须抛出异常，让调用者（或者 Laravel 的 ExceptionHandler）去负责渲染或者返回错误信息。