Это хорошая практика для создания объекта контроллера в другом контроллере после MVC в PHP?

Question

Мы все (большинство из нас) знаем, что работа контроллера заключается в обработке запроса, сделанного клиентом (например, веб-браузером), получении модели, представлении представления.

Мой старший разработчик имеет 20-летний опыт работы,вырос на родном PHP, в отличие от меня 4 года опыта, вырос на PHP MVC фреймворках.Я видел, как мой старший разработчик создает объект контроллера в функции действия другого контроллера, потому что он хочет использовать ту же бизнес-логику, что и в следующем примере.

class FooController extend Controller {

     public function view($id) {

         // Business logic goes here...

         // Pseudo code
         // If request comes from BarController
         // Render no layout, only view template.


         // If request comes from browser
         // Render view template with layout.
     }
}

class BarController extends Controller {

     public function viewFoo($id) {

          // Create an object of FooController so that we can reuse the business logic of the view function.
          $foo = new FooController();
          $foo_view = $foo->view($id);

          // Render $foo_view template.
     }
}

Является ли это хорошей практикой для создания объекта контроллера(в данном случае FooController) в другом контроллере (в данном случае BarController::viewFoo($id)), следуя шаблону проектирования MVC?

Answer 1

В некоторых ситуациях это может быть хорошо, но в целом это признак проблем.

По мнению некоторых людей, бизнес-логика многократного использования не принадлежит контроллеру.Вместо этого они рекомендуют некоторые варианты «жирной модели тощий контроллер» (поместите эти термины в поисковой системе Интернета).Контроллеры должны быть действительно простыми, а логика многократного использования должна находиться на уровне модели или на отдельном уровне сервисов.

Учитывая это, большинство людей предполагает, что контроллеры не используются повторно, как это.Это делает приложение хрупким: представьте, что кто-то меняет повторно используемый контроллер или представление, которое он отображает: они не будут знать, что им нужно протестировать эту несвязанную часть приложения.