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

前言

当我们谈论应用程序的架构时，我们经常会问一个经典的问题，那就是“这些代码应该放在哪里？”。因为Laravel是一个相当灵活的框架，所以回答这个问题并不那么容易。我应该在模型层、控制器层还是其他地方编写我的业务逻辑？

当您的应用程序只有一个访问点时，可以在控制器层中编写业务逻辑。但是现在更常见的是有很多接入点调用同一个功能模块。

比如太多的应用有用户注册的功能，它的过程就是调用一个控制器，然后返回注册成功或失败的视图。如果这个应用有移动终端，很可能会提供一套移动终端用户注册的API，因为它需要返回的数据格式是JSON。而且，使用Laravel的artisan命令来创建用户是非常常见的，尤其是在项目的早期开发阶段。

以上两段代码看起来可能没有什么问题，但是随着业务逻辑的增加，就会出现代码冗余的情况。例如，如果需要在新用户注册后添加向其发送电子邮件通知的功能，则必须向上述两个控制器添加发送电子邮件的代码。但是如果我们想保持代码简单优雅，我们可以在其他地方编写这些业务逻辑。

对于“业务逻辑代码写在哪里”这个问题，去任何论坛都可以得到一个大概的答案，那就是“使用一个服务层，然后在控制器层调用这个服务类”。是的，没错。问题是，我们应该如何设计服务类？是创建一个UserService类来实现所有与用户相关的业务逻辑，然后将这个类注入到所需的Controller层吗？还是有别的计划？

避开神的坑

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

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

例如，当我们为用户创建一个帐户时，我们也应该为用户创建一个单独的博客。如果我们以当前的方式实现这个过程，我们必须创建一个BlogService类，并将它的依赖项注入到UserService类中。

显然，随着应用业务的增长，将会出现几十到几百个服务类，其中一些需要依赖5到6个其他服务类。最后的结果是代码的冗余和混乱，这是我们不惜一切代价想要避免的。

介绍单一行动类

因此，如果我们不使用单个服务类并添加几个方法，我们决定将其分成几个类。以下是我最近每个项目都采用的方法，效果很好，推荐给大家。

首先，让我们摆脱过于笼统和模糊的服务术语，了解我们的新动作类，并定义它们是什么以及它们能做什么。

动作类应该有一个可以解释其功能的名称，例如：创建订单、确认结帐、删除产品、将产品添加到购物车等。它应该只有一个公共方法作为API。理想情况下，它应该是相同的方法名，如handle()或execute()。如果我们需要为我们的动作类实现一些适配器模式，这是非常方便的。它必须对请求和响应不可知。它不处理请求或发送响应。这种责任应由财务主任承担。它可以依赖于其他动作类。如果有什么阻止它执行和/或返回预期值，它必须通过抛出异常来强制执行相关的业务逻辑，并让调用方(或Laravel的ExceptionHandler)承担如何呈现/响应异常的责任。创建我们的创建用户操作类

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

您可能想知道为什么当电子邮件地址已经被占用时，此方法会引发异常。这不是通过请求身份验证来保证的吗？当然可以。但是，在动作类内部执行业务逻辑不是更好吗？这使得逻辑易于理解和调试。

让我们在使用我们的动作类之后看看控制器代码，如下所示：

现在不管我们做什么改动，用户注册流程都是用API和Web版本来处理，优雅整洁。

动作类的嵌套

假设我们需要一个动作类来将1000个用户导入到我们的应用程序中。我们可以编写一个动作类，并继续使用上面的CreateUser类：

很整洁，不是吗？我们可以通过将CreateUser代码嵌入Collection:map()方法来重用它，然后返回所有新创建的用户的集合。当邮件被占用时，我们可以返回空对象或将其记录在日志文件中，您应该已经想到了这一点。

动作类装饰

现在，假设我们想在日志中记录每个新注册的用户。我们可以在动作类中编写代码，也可以使用装饰器模式。

然后，我们可以使用Laravel的IoC容器将LogCreateUser类绑定到CreateUser类，只要我们需要后者的实例，就会注入前者：

AppServiceProvider.php

这使得使用配置或环境变量来控制日志记录功能的激活或停用变得更加容易：

AppServiceProvider.php

摘要

使用这种方法似乎需要很多类。当然，用户注册只是一个简单的例子，旨在保持代码的简短和清晰。一旦项目的复杂性开始增长，动作类的真正价值就变得越来越明显，因为你清楚地知道代码在哪里以及它的定义。

使用单个操作类的好处：

小而单一的逻辑域可以防止代码重复，提高代码的可重用性，保持稳定性。很容易针对各种场景进行独立测试。有意义的命名在大型项目中更容易阅读。易于装饰。整个项目的一致性：防止代码分布在控制器、模型等中。当然，这种方法是基于我过去几年使用Laravel的经验和我在一些项目中的实践。这对我真的很有用，现在我甚至在一些中小型项目中使用它。

如果你有不同的方法，我期待着阅读它们。

摘要

以上就是本文的全部内容。希望本文的内容对大家的学习或工作有一定的参考价值。有问题可以留言交流。谢谢你的支持。