Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Всерьёз занявшись улучшением поддерживаемости кода, создал поля класса контроллера и добавл конструктор. Попробовал осуществить запрос к базе данных в конструкторе (вернее, вызвать соответствующий метод из конструктора), а не как обычно (то есть в методе, вызываемого из маршрутов web.php, в примере ниже — renderTopPage). Работает.
class TopPageController extends Controller {
private $pageHtmlHeadData;
public function __construct() {
$this -> pageHtmlHeadData = $this -> getTopPageHtmlHeadData();
}
public function renderTopPage(){
// код этого метода не нужен в данном примере, но именно этот метод вызывается из web.php
}
private function getTopPageHtmlHeadData(){
retrun // SQL запрос к БД ...
}
}
Вопрос такой: а будет ли выигрыш в скорости генерации страницы засчёт того, что SQL-запрос был выполнен до метода, где создаётся вид? Я бы смог ответить на этот вопрос, если бы знал, когда создаётся экзепляр контроллера (а он где-то создаётся, хотя у родительских классов конструкторов нет).
Изменено Gleb2708 (01.02.2018 11:20:51)
Не в сети
В вашем случае профит близится к нулю. Конструктор нужен для первоначальной инициализации класса. Например логика лежит по нескольким методам, которым нужны какие-то общие какие-то первоначальные данные.
Не в сети
Не в сети
Не буду врать, не особо интересовался. Мне достаточно знать в общих чертах лайф цикл.
Не в сети
Мастер 
А Вы можете сказать, в какой момент создаётся экземпляр контроллера?
Прямо перед вызовом нужного action контроллера.
framework/src/Illuminate/Routing/Route.php метод run() -> runController()
runController() дергает getController()
метод getController() создает экземпляр контроллера
Выигрыша нет никакого.
И вряд ли это можно назвать "улучшением поддерживаемости кода".
Изменено covobo (01.02.2018 15:04:58)
Не в сети
Писарь 
ПМСМ, поддерживаемость улучшается тогда, когда увеличится специализация классов и методов. Это НЕ приводит к ускорению. Вероятно даже, что бОльшая специализация приведёт к некоторому оверхеду. У всего есть своя цена.
В плане специализации, то что ты вынес добычу данных в отдельный метод это плюс. Это упрощает будущее обслуживание кода. Опять же по моему субъективному мнению, в конструктор имеет смысл помещать то, что будет общим для любого экшена. Если только для 2/3, то уже не стОит, т.к. оно будет сбивать с толку читателя.
Ещё лучше станет, если в контроллере не будет ничего сложнее элементарных $repo->getThing($arg) — неважнов конструкторе или в любом другом методе. Когда появляется цепочка построителя запроса или готовый сырой SQL, это лучше вынести в отдельный класс, неважно как его назовёшь: "модель" или "репозитарий". В специализированный не-контроллер. 
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)