Laravel程序架构设计思路之使用动作类

前言

当我们谈论到应用程序的架构的时候，经常会问到一个经典的问题，那就是“这段代码应该放在哪里比较好”。 因为 Laravel 是一个相当灵活的框架，所以要回答这个问题其实没那么容易。我应该把我的业务逻辑写在 Model 层，还是 Controller 层，或者是其他地方？

当你的应用程序仅有一个接入点，把业务逻辑写在 Controller 层是可以的。但是现在更普遍的的情形是，有很多接入点去调用相同的功能模块。

比如说，太多数的应用程序都有用户注册的功能，它的流程是调用一个控制器然后返回一个注册成功或者失败的视图。假如这个应用程序还有移动端，那就很可能要提供一套针对移动端用户注册的 API ，因为它需要返回的数据格式是 JSON 。而且利用 Laravel 的 artisan 命令来创建用户也很常见，尤其是在项目前期的开发阶段。

上面这两段代码可能看起来没有什么问题的，但是，随着业务逻辑的增加，就会显得代码很冗余。举个例子，如果你需要新用户注册完之后，增加给用户发送邮件通知的功能，你必须要再上面两个控制器中都添加发送邮件的代码。但是如果要保持代码的简洁优雅，我们可以把这些业务逻辑写到其他地方。

对于“把业务逻辑代码写到哪里”的这个问题，你去任何论坛都可以得到一个普遍的答案，那就是 “使用一个 service 层，然后在 controller 层调用这个服务类”。是的，没错，问题是我们应该怎么设计 service 类？是创建一个 UserService 类来实现所有跟用户用户有关的业务逻辑，然后把这个类注入到需要用到的 Controller 层？或者是还有其他方案？

避免神类的坑

首先，可以尝试为一个特定的模型创建一个单一类，其中包含所有的代码。例如：

看起来很完美：我们可以任何控制器中申明或者使用 create/delete 方法，并且得到我们想要的结果。但是，这种实现有什么问题呢？ 那就是我们在解决问题的过程通常很少使用单一的模型 。

比如说，当我们给一个用户创建了账号的时候，也要同时给用户单独创建一个 blog 。如果按照当前的方式去实现这个流程，我们就必须创建一个 BlogService 类，然后将其依赖注入到 UserService 类。

显而易见，随着应用程序的业务的增长，将会有几十到上百个 service 类，其中的一些 service 类需要依赖 5 到 6 个其他 service 类，最终的结果就是，出现代码的冗余跟混乱的局面，而这个局面是我们想不惜一切代价去避免的。