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 。
你或许想知道当邮箱地址已经被占用时，该方法为什么会抛出了异常。 这难道不是请求验证来保证的吗？当然可以。然而，在动作类内部来执行业务逻辑不是更好吗？这样使得逻辑变得易于理解和调试。
让我们看看使用我们动作类之后的控制器代码，如下：
现在，无论我们做什么修改，用户注册过程都会由 API 和 Web 版本处理，优雅整洁。
动作类的嵌套
假如，我们需要一个动作类将 1000 个用户导入我们的应用中。我们可以写一个动作类，并且继续使用上文的 CreateUser 类：
非常整洁，不是吗？我们可以通过将其嵌入在 Collection::map() 方法中来重用 CreateUser 代码，然后返回所有新建用户的集合。当邮件被占用的时候，我们可以通过返回 Null Object 或者在 Log 文件中记录一下，你应该已经想到了。
动作类的装饰
现在，假设我们想在日志中记录每一个新注册的用户。我们可以将代码写在动作类内部，也可以使用装饰者模式。
然后，我们可以使用 Laravel 的 IoC 容器将 LogCreateUser 类绑定到 CreateUser 类，所有每当我们需要一个后者的实例时，前者都会注入进来：
AppServiceProvider.php
这使得使用配置或环境变量来控制日志记录功能的激活或停用更为方便：
AppServiceProvider.php
总结
使用这个方法似乎会需要很多的类。当然，用户注册仅仅是一个简单的例子，旨在保证代码的简短清晰。一旦项目的复杂度开始增长，动作类的真正的价值就越来越明显，因为你清晰的知道代码所在及其界定。
使用单动作类的好处：
- 小巧而单一的逻辑域能够防止代码重复并提高代码的可重用性，保持稳定。
- 易于针对各种场景进行独立测试。
- 富有意义的命名在大型项目中更容易阅读。
- 易于装饰。
- 整个项目的一致性：防止代码分布在 Controllers、Models 等。
当然，这个方法是基于我过去几年使用 Laravel 的一些经验和我在一些项目中的实践。这对我真的很有用，现在我甚至在一些中小型项目中使用。
如果你有不同的方法，我非常期待读一读。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。
以上是 Laravel程序架构设计思路之使用动作类 的全部内容， 来源链接： utcz.com/p/221958.html
