Мы все (большинство из нас) знаем, что работа контроллера заключается в обработке запроса, сделанного клиентом (например, веб-браузером), получении модели, визуализации представления.
Мой старший разработчик имеет 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?
Эта практика может быть приемлемой в некоторых ситуациях, но в целом это признак проблем.
По мнению некоторых людей, бизнес-логика многократного использования не принадлежит контроллеру. Вместо этого они рекомендуют некоторые варианты «жирной модели тощий контроллер» (поместите эти термины в поисковую систему Интернета). Контроллеры должны быть действительно простыми, а логика многократного использования должна находиться на уровне модели или на отдельном уровне служб.
Учитывая это, большинство людей предполагает, что контроллеры не используются повторно, как это. Это делает приложение хрупким: представьте, что кто-то меняет повторно используемый контроллер или представление, которое он отображает: они не будут знать, что им нужно протестировать эту несвязанную часть приложения.
Других решений пока нет …