PHP开发环境在过去几年发生了很大变化。我们开始使用更多更好的设计模式（如DRY和SOLID）设计模式原则。但是为什么我们还在使用控制器呢？如果您以前参与过编写大型项目的架构，您可能已经注意到迟早会有太多控制器。即使你将控制器逻辑分离到各种类库或服务类中，大量的依赖项和方法以及代码行数也会随着时间的推移不断增长。让我介绍一下请求处理程序。这个概念很简单，但很多PHP开发人员都不知道。请求处理器可以理解为只包含单个动作（Action）的控制器，可以使从请求到响应的过程更加清晰。这个概念与PaulM.Jones提出的Action-Domain-Responder设计模式有相似之处，后者是MVC模式的替代方案。创建请求处理程序的一个好方法是使用调用者类。Callable类在PHP中使用魔术方法__invoke，将它们变成Callable，这将允许它们作为函数被调用。下面是一个调用类的简单示例：classGreeting{publicfunction__invoke($name){echo'Hello'.$名称；}}$welcome=newGreeting();$welcome('JohnDoe');//输出HelloJohnDoe当你看到这个时，你可能会想；“我为什么要这样做？”。我知道这是一个有点荒谬的例子。但是当与某些代码（例如可调用对象和依赖注入）一起使用时，它就变得有意义了。一个很好的用例是Laravel和Slim框架中的路由请求处理。Route::get('/{name}',Greeting::class);让你吃惊？不？让我们将其与您通常编写的内容进行比较：Route::get('/{name}','SomeController@greeting');然而？除了代码好看，还有其他优点。让我们首先看一下使用请求处理程序相对于控制器的优势。单一模式SOLID的首要原则是“单一模式”。在我看来，controller中有很多方法，打破了这个原则。请求处理程序提供了一个很好的解决方案，可以将这些操作分离到它们自己的类中，从而使它们更易于维护、重构和测试。这是从UsersController中提取的2个请求处理程序的示例，用于处理编辑和保存用户配置文件：{...}}classUpdateUserHandler{publicfunction__construct(UserRepository$repository,UpdateUserValidator$validator,ImageManager$resizer,Filesystem$storage){...}publicfunction__invoke(Request$request,Response$response){...}}接下来我们来看下一个优势；测试性能您最近是否为您的项目编写了单元测试？在编写单元测试时，您可能会编写一些与测试无关的模拟依赖项。由于请求处理程序将不同的控制器操作拆分为单独的类，因此您只需注入或绑定该操作所需的依赖项。以下是JeffreyWay在Twitter上的一些建议。提示：使您的功能测试尽可能具体，使用测试用例来描述重要的规则和功能。这基本上不会为您的每个请求处理程序提供测试文件。对那些繁琐的控制器测试文件的一个非常好的改进。重构PhpStorm等编辑器具有强大的代码重构能力，但是如果你使用Laravel或Slim框架的默认路由方式将控制器绑定到路由，那么你可能会遇到这个问题。例如重命名：Route::get('/{name}',Greeting::class);比这简单得多：Route::get('/{name}','SomeController@greeting');结束语请求处理控制器是控制器的一个很好的替代品。控制器的动作（Actions）分为多个独立的请求处理器类，每个类负责响应单个动作。这使得整个项目的代码更易于维护、重构和测试。您应该用请求处理程序替换所有控制器吗？也许不会。对于小型应用程序，为简单起见，将操作组合到控制器中可能更有意义。当我开始使用Teamleader时，我才开始深入研究请求处理程序，而且我认为没有必要很快切换回控制器。如果有任何不清楚或有疑问，请在下面发表评论让我知道，我会更新这篇文章。转自PHP/Laravel开发者社区https://laravel-china.org/top...
