Разве плохо вводить класс контроллера в класс контроллера?

Стараясь следовать принципу единой ответственности, я решил, что при рендеринге формы представления я могу перейти в другой класс. Также для рендеринга формы я уже планирую использовать 5 зависимостей. Таким образом, основной контроллер, который внедряет форму, будет иметь меньше зависимостей, что хорошо.

Я никогда не вводил классы контроллера в класс контроллера. Обычно я создаю библиотеку. У меня есть папка библиотеки, сделанные как брат к папке контроллеров.

Но теперь подумайте — может быть, лучшей идеей было бы ввести еще один контроллер в контроллер?

Пытался искать это, но не нашел примеров. Но в то же время попытался создать контроллер с помощью только функции конструктора и отобразить строку. Затем введите этот контроллер в другой. И строка отображается

Таким образом, это означает, что возможно ввести контроллер в контроллер. Так это хорошо? Или, может быть, это будет необходимо?

По умолчанию у laravel нет даже папки с библиотеками, что интересно, возможно создатели предполагают, что она не нужна.

0

Решение

Да, это плохо. Контроллеры не только должны нести одну ответственность, но они также представляют собой другой класс, который должен иметь только одну работу: Контроллер — это прокси между 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.

2

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]