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

[Вурдалак]

Запрещать может code style проекта или ревьюер. Так-то и $_GET и global никто не запрещает, ога.

Так я и говорю: PHP — говно.

 

[fixxxer]

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

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

 

[Вурдалак]

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

инжектить TemplateEngine внутри контроллера

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

 

[fixxxer]

Особенно, когда интернет переполнен восторженными отзывами типа «ох, мой бох, фасады в ларавел, это гениально».

Не читай хабрахабр по утрам.

 

[slider23]

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

А какой фреймворк настаивает о таких вещах ?

 

[Вурдалак]

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

 

[AmdY]

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

 

[Вурдалак]

AmdY, куча зависимостей — это не проблема?

 

[AmdY]

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

 

[Вурдалак]

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

 

[fixxxer]

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

В этом смысле джавовский @Inject/@Autowired ничем не лучше: их с такой же легкостью можно наплодить 100500 штук.

 

[Вурдалак]

В этом смысле джавовский @Inject/@Autowired ничем не лучше: их с такой же легкостью можно наплодить 100500 штук.

А я как раз аннотации не люблю. И да, инъекция напрямую в private ничем не лучше.

 

[fixxxer]

И да, инъекция напрямую в private ничем не лучше.

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

 

[AmdY]

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

 

[Вурдалак]

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

 

[Absinthe]

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

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

 

[keltanas]

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

 

[hell0w0rd]

keltanas,

или методов-хелперов суперконтроллера

А еще трейты, в них можно как раз методов доступа к репозиториям напихать и использовать нужные.

 

[keltanas]

А еще трейты, в них можно как раз методов доступа к репозиториям напихать и использовать нужные.

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

 

[Вурдалак]

напихать и использовать нужные.

Логика Service Locator'а.