Разве плохо вводить класс контроллера в класс контроллера?
Стараясь следовать принципу единой ответственности, я решил, что при рендеринге формы представления я могу перейти в другой класс. Также для рендеринга формы я уже планирую использовать 5 зависимостей. Таким образом, основной контроллер, который внедряет форму, будет иметь меньше зависимостей, что хорошо.
Я никогда не вводил классы контроллера в класс контроллера. Обычно я создаю библиотеку. У меня есть папка библиотеки, сделанные как брат к папке контроллеров.
Но теперь подумайте — может быть, лучшей идеей было бы ввести еще один контроллер в контроллер?
Пытался искать это, но не нашел примеров. Но в то же время попытался создать контроллер с помощью только функции конструктора и отобразить строку. Затем введите этот контроллер в другой. И строка отображается
Таким образом, это означает, что возможно ввести контроллер в контроллер. Так это хорошо? Или, может быть, это будет необходимо?
По умолчанию у laravel нет даже папки с библиотеками, что интересно, возможно создатели предполагают, что она не нужна.
Решение
Да, это плохо. Контроллеры не только должны нести одну ответственность, но они также представляют собой другой класс, который должен иметь только одну работу: Контроллер — это прокси между HTTP-запросом и вашим приложением (модели, репозитории, виды). Поэтому в основном он должен получить HTTP-запрос, получить некоторые данные из ваших моделей и передать их в представление.
Все остальное должны делать ваши классы поддержки (модели, репозитории, помощники, композиторы и т. Д.).
Если вам нужно вызвать второй класс контроллера, возможно, вам нужны методы на этом контроллере, которых не должно быть в этом контроллере, потому что ваши контроллеры делают больше, чем их работа.
Это один из моих контроллеров:
class Connect extends BaseController {
public function index()
{
$connections = $this->execute(GetConnectionsCommand::class);
return View::make('connections.index')->with('connections', $connections);
}
}
Там много чего происходит за кулисами в этом GetConnectionsCommand чтобы получить информацию, чтобы показать все соединения, и мой контроллер не должен знать обо всем этом.
В этом представлении «connections.index» есть некоторые подпредставления, но вызов подпредставлений является обязанностью представления, моему контроллеру не нужно знать, что конкретное представление нуждается в представлении подпредставлений. Я могу иметь master вид и некоторые @ifвнутри, чтобы сделать их все правильно.
Контроллер возвращает данные (визуализированное представление, представленное другим классом) обратно в объект ответа (за кулисами в Laravel), который отвечает за эффективную визуализацию данных, которые будут переданы обратно в ваш браузер. Таким образом, контроллер находится прямо посреди чего-то, делая очень маленький оркестр, потому что чем больше он знает о вашей бизнес-логике, тем больше вы чувствуете, что ему нужно «поговорить» с другим контроллером. Вы можете думать о нем как о MVP, если хотите, но это чистый MVP, использующий принцип единой ответственности, как и должно быть. Но в этом случае контроллер не отделен от представления, потому что нет интерфейса между ними, так что это на самом деле не MVP.
Другие решения
Других решений пока нет …
detector