首页 > 文章 > 后端开发 > Laravel程序架构设计之动作类的使用

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

不言原创: 2018-06-08 09:08:141949浏览

这篇文章主要给大家介绍了关于Laravel程序架构设计思路之使用动作类的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧

前言

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

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

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

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

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

避免神类的坑

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

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

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

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

介绍单动作类

那么，如果不是用一个单一的服务类加上几个方法，我们决定把它分成几个类？下面是我最近每一个项目都采用的方法，结果很不错，推荐给大家。

首先，让我们抛弃过于笼统和模糊的服务术语，来了解一下我们的新动作类，并定义它们是什么以及它们可以做什么。

一个动作类，应该有一个能够说明其功能的名字，比如：CreateOrder, ConfirmCheckout, DeleteProduct, AddProductToCart等。
它应该有且只有一个公共方法，作为 API 。理想的情况下，应该是相同的方法名，像 handle() 或者 execute() 。如果需要对我们的动作类实现某种适配器模式，这是非常方便的。
它必须对请求和响应不可知。它不处理请求，也不发送响应。这样的职责应该由控制器来承担。
它可以依赖其它的动作类。
如果有任何事情阻止它执行和/或返回期望的值，那么它必须通过抛出一个 Exception 来强制执行相关的业务逻辑，并且让调用者（或者 Laravel 的 ExceptionHandler ）来承担如何呈现/响应异常的责任。

创建我们的 CreateUser 动作类

现在，让我们看看前面的例子，并用一个单动作类来重构它，我们将命名为 CreateUser 。