Laravel Чем вызван взрывной интерес к Лярве?

fixxxer

К.О.
Партнер клуба
Laravel мультипарадигменный в том же смысле, в котором php - говно. ;)

Хотя я в этом смысле не знаю ни одного нормального скриптового языка. Тем более, что правильный современный ООП классическими средствами (паттерны) довольно утомителен без языковой поддержки.
 

Вурдалак

Продвинутый новичок
fixxxer, проблема лишь в том, что большинство разработчиков, я уверен, не осознают где та граница где можно юзать фасады, а где — нет. Особенно, когда интернет переполнен восторженными отзывами типа «ох, мой бох, фасады в ларавел, это гениально». Я троллю не просто так.

инжектить TemplateEngine внутри контроллера
Делаешь parent service с абстрактным контроллером, который содержит набор хелперов типа $this->render() и инжектишь с помощью сеттеров. То же самое по удобству.
 

slider23

Новичок
Самое парадоксальное, что основная фича ваших фасадов и есть проблема. Получить инстанс легко откуда угодно, а это в свою очередь означает, что люди меньше задумываются о таких вещах, как декомпозиция, SRP, etc.
А какой фреймворк настаивает о таких вещах ?
 

Вурдалак

Продвинутый новичок
Фреймворк, как и любой другой инструмент, не может настаивать на таких вещах, но может меньше провоцировать и помогать обнаруживать проблемы. Я убежден, что если в конструктор класса требуется заинжектить over 10 сервисов, то любой человек поймёт, что тут что-то не так. А если я могу дёрнуть любой сервис без каких-то дурацких инъекций, то я могу убедить себя, что проблемы как бы и нет.
 

AmdY

Пью пиво
Команда форума
Вурдалак, так это и не проблема, может действительно не нужно всё инджектить?
 

AmdY

Пью пиво
Команда форума
Вурдалак, это проблема, используется DI или просто new Class. Ну и laravel есть фасады, так что можно обходиться без инъекций при этом код останется тестабилити.
 

Вурдалак

Продвинутый новичок
AmdY, а как одно заменяет другое, фасады — те же зависимости, только неявные. Инъекция лишь помогла бы быстрее обнаружить проблему или, по крайней мере, заставить сделать декомпозицию. Я много раз видел, как злоупотребляют синглтонами, тупо потому что заставляет меньше задумываться.
 

fixxxer

К.О.
Партнер клуба
Фреймворк, как и любой другой инструмент, не может настаивать на таких вещах, но может меньше провоцировать и помогать обнаруживать проблемы. Я убежден, что если в конструктор класса требуется заинжектить over 10 сервисов, то любой человек поймёт, что тут что-то не так. А если я могу дёрнуть любой сервис без каких-то дурацких инъекций, то я могу убедить себя, что проблемы как бы и нет.
В этом смысле джавовский @Inject/@Autowired ничем не лучше: их с такой же легкостью можно наплодить 100500 штук.
 

fixxxer

К.О.
Партнер клуба
И да, инъекция напрямую в private ничем не лучше.
Так и я об чем: фасады - это, по сути, то же, что @Autowired-инъекция. Выглядит более пугающее, т.к. похоже на статический вызов, но по сути - те же яйца. Соответственно, исключая целиком это дело, имеем классическую писанину с передачей зависимостей, либо инстанциацию всего подряд через DI. Передача таким образом, скажем, какого-нибудь сраного логгера - это очень удручающее занятие. Потому, как по мне, - лучше иметь выбор, и при написании кода использовать головной мозг по назначению.
 

AmdY

Пью пиво
Команда форума
Вурдалак, инджект требует передачи параметров извне, в случае ларавел нужно использовать App::make('Class'), в классах захламлять конструктор и не дай бог он перегружен и parent требует своих зависимостей. С фасадами же код пишется в самом методе и зависимости подтягиваются изнутри, что нагляднее и не требует построения цепочек вызовов с пробрасыванием зависимостей. Не надо сюда прикреплять синглетон, он для других целей,а не для зависимостей. App::make ещё и авторефакторинг ломает, как и другие контейнеры. Инджект такая же обоюдоостра штука как и любой другой способ решения зависимостей.
 

Вурдалак

Продвинутый новичок
AmdY, зависимости никуда не деваются, называй их как хочешь. Только непонятно кого ты обманываешь, говоря, что конструктор не захламлён: какая разница какой конструктор, если класс в любом случае требует 100500 объектов, которые спрятаны в фасады?
 

Absinthe

жожо
AmdY, не надо путать "меньше телодвижений" и "что нагляднее".
Пользуясь ларавелом мы идем на компромис говнокода (относительно честного DI) и скорости разработки.

И я считаю, что некоторое количество осознанного говнокода делает жизнь проще. И мне нравится Laravel.
 

keltanas

marty cats
AmdY, Вурдалак, есть ощущение, что вы о разном спорите ))
Если речь о контроллере, то в целом нет разницы, будут ли фасады в виде классов, или методов-хелперов суперконтроллера (хотя второй вариант мне больше по душе).
Но, я надеюсь никто не отстаивает подход построения бизнес-логики или логики приложения на фасадах? :)
 
  • Like
Реакции: AmdY

keltanas

marty cats
А еще трейты, в них можно как раз методов доступа к репозиториям напихать и использовать нужные.
У меня патологическая неприязнь к трейтам )) Имхо, это какой-то стрёмный способ лепить монстра Франкенштейна. К тому же в трейте автокомплит не работает (т.к. трейт не знает, к кому он будет притрейчен). А у $this->getDoctrine()->gerRepository(..) работает, когда phpstorm с плагином symfony :)
 
Сверху