Философия RAD и Enterprise фреймворков
Как и обещали, выкладываем запись вводного урока нашего мастер-класса про философию Symfony и других фреймворков и про основные требования, предъявляемые заказчиками и программистами к фреймворкам:
- Сравнили подходы к разработке
- Узнали, что требуется от фреймворка
- Сравнили Symfony с другими фреймворками
- Узнали, в каких ситуациях какой фреймворк выбирать
Для более комфортного просмотра откройте скринкаст на YouTube, разверните видео до оригинального размера значком и поставьте скорость 1,25:
На следующем уроке займёмся установкой и настройкой Symfony и поднятием окружения в Docker:
Страница мастер-класса с записями
1. PHP Templating вполне часто встречается в реальных проектах.
2. Как косяки того же Yii приводится то, что PSR-ки не поддерживаются. В 2.x это так. К сожалению, такой же косяк скоро можно будет предъявлять Laravel и Symfony потому как из PHP-FIG они вышли :(
3. Inject-ить контейнер в Symfony, использовать lifecycle event-ы в Doctrine, устраивать event hell и вот это всё — вполне распространённая практика в реальных проектах.
Symfony позволяет делать некоторые штуки, которые в Yii делать не удобно или почти невозможно. Например, использовать namespace чтобы группировать код по модулям (в понимании DDD, то есть модуль === use case). Хотя, конечно, и там это делается немного неприятно. Приходится очень и очень сильно раздувать конфиг.
1. Это сознательный отказ от шаблонизатора.
2. Вы как разработчик Yii участвуете в PHP-FIG, но Yii от этого PSR-ок всё равно не поддерживает. Авторы Laravel и Symfony могут там не участвовать в обсуждениях и голосованиях, но фреймворки их поддерживают ради удобства пользователей. Так что спорная аналогия.
3.1. Специально для этого конкретного случая инжекта контейнера если он нужен как сервис-локатор там даже придумали отдельный контейнер-песочинцу, который можно ограничить от злоупотреблений белым списком сервисов. Его мы уже обсудили пару лет назад. И даже если инжектить оригинальный контейнер вместо локатора, то чтобы из него можно было достать какой-либо сервис в конфиге этому сервису нужно явно включить public=true. Или включить public глобально и увидеть сотню ошибок от autowiring. То есть по умолчанию из коробки всё максимально закрыто и все лазейки нужно включать самому, огребая встречных проблем от такой самодеятельности.
3.2. В lifecycle-евентах из самой сущности невозможно достать контейнер, чтобы из него достать Request или Mailer. Придётся делать отдельный Listener или Subscriber по аналогии с Yii Behavior. Но такой программист сразу же увидит нежизнеспособность своей затеи, как только попробует загрузить фикстуры для демо-данных и для интеграционных тестов. Так что и здесь накосячить не получится.
В Yii контейнер по умолчанию работает в фабрике Yii::createObject для всех классов в режиме singleton=false, а не как сервис-контейнер только для хранения сервисов с singleton=true. Поэтому для исправления ситуации тоже приходится раздувать конфиг, все классы сервисов прописывая в singletons.
2. Yii 3.0 будет поддерживать, дело не в Yii.
У Symfony же есть свой устоявшийся request/response, свои middleware и вот это всё, а так как два популярных фреймворка работают на одной базе, это близко к монополии и можно форсить vendor lock вместо interoperability. Да, есть PSR-7 Bridge, но по факту многие решения из за такого положения дел завязываются именно на HttpFoundation, а не на PSR. См. symfony-leaves-php-fig (ресурс, конечно, не лучший, но саммари норм). Хуже фреймворк, конечно, от этого не станет, но часть аргументов из скринкаста не вполне корректны в этом свете.
3.2. Получится. Это это видел :) Тесты пишут не все. Иногда забивают на юнит и фигачат, например, в gherkin на behat всё.
Я не говорю что в Yii 2 всё круто. Мне раздутие конфига неприятно одинаково как в Yii, так и в любом другом фреймворке. Не люблю config-driven development.
2. Да, есть свой отличный чистый HTTP Foundation и к нему PSR-7 Bridge. Так что можно легко использовать любой вариант или промежуточные и ни у кого с этим проблем нет. И любые такие "многие решения" при необходимости перевязать через этот мост. А то, что отказываются от некоторых PSR-ов в ядре - также как с PSR-7 сделают отдельные Bridge вне ядра.
3.2 Ну слишком крайние случаи рассматривать не будем :)
2. Использовать — да, тут проблем почти нет. На самом деле под тот же Yii 2 есть тоже мосты... даже под первый: yii1-psr3-logger-bridge. Вот только умолчание — не использовать PSR, а вязаться на HTTP Foundation, что сокращает число тех же middleware и библиотек, доступных для разработки на PHP в общем, а не только на Symfony. С точки зрения стратегии захвата рынка это правильно, а вот с точки зрения светлого будущего для PHP в целом — нет.
3.2. Они не слишком. Таких большинство.
3.2. Ну может. А на форуме прямо после урока свежий пример возник с героическим решением (и не одним) на StackOverflow :)
Ребята, ну вы тут устроили конечно ад.
Фреймворк ну никак не влияет на возможность или на НЕвозмодность писать говнокод.
Уровень кода зависит от уровня того, кто его пишет (о как!).
Пока человек пишет на Yii и НЕ пишет тесты - он не поймет, что Yii::app->request или BlamableBehavior - это зло. Как только он напишет первый тест - на него опустится озарение и он просто напросто начнет думать (и перестанет писать херню). Откройте гитхаб - сотни проектов на ларке, которые написаны хуже чем на Уии. Мне на фрилансе попадался просто ад и треш что на симфони, что на уии, что на ларе.
Если говорить конкретно про Yii, то все сводится к написанию 5-10 правил разработки для команды, например у нас там вот такие пункты:
- за Yii::app вне контроллера - смерть
- за before*, after* методы в моделях - смерть
и т.д.
Да, зависит от разработчика. И плюс от того, что у него есть.
> к написанию 5-10 правил разработки для команды
Это и есть дисциплина, которую мы обсудили.
> за Yii::app вне контроллера - смерть
> за SQL-запросы в представлениях - смерть
Про это и сказал, что если фреймворк такие вещи позволяет, то приходится придумывать десятки пунктов и вручную материть программистов за фасады и app. За этим приходится следить самому.
А с фреймворком без фасадов и со строгим шаблонизатором такие пункты не нужно вообще придумывать, так как там это невозможно из коробки.
Зато в фреймворке без фасадов и со строгим шаблонизатором возможно объявить в качестве зависимости интерфейс и начать использовать внутри методы отсутствующие в этом интерфейсе....
А так-то да - зашибись все в Симфони...
Такое и в Java легко сделать через каст.
А чем плохи фасады, можете обьяснить? Спасибо!
Андрей, а вы не могли бы опубликовать полный список правил? Если есть список правил с причинами - то тоже. Очень полезная информация была бы, особенно для начинающих.
у нас там вот такие пункты
Огласите весь список, пожалуйста! ©
Отличное видео! Очень много полезных моментов разобрано!
Посмотрел на одном дыхании, спасибо!
Я планирую приобрести мастер-класс и большую часть видео планирую смотреть в записи так как по субботам вечером не всегда будет получаться.
Дмитрий, дальнейшие видео так же будут редактироваться перед публикацией как и это?
Отредактированный материал мной лучше воспринимается:)
Да, будет.
Создалось впечатление (разумееется, ложное) будто симфони-проекты по умолчанию прекрасно написаны и не подвержены ошибкам )
Также как везде, люди имплементят бизнес логику в life cycle эвентах (не всегда для этого нужен реквест), юзают доктрину как актив рекорд, не пользуются доменными эвентами.
Ты бы лучше хоть немного рассказал, что ты в мк будешь внимание уделять в том числе и нормальным практикам, а не пытаться всех убедить, что симфони это что-то не допускающее ошибок.
Дмитрий, спасибо за доклад!
И спасибо за таймкоды в описании )
Спасибо. Интересно было услышать. Особенно про твой рост, сам попробовал симфони - не сильно хочется возвращаться на yii2 (особенно когда руководство перестало экономить на юнит тестах). К сожалению есть легаси и его нужно поддерживать. Стоило также упомянуть что симфони это по структуре копия спринга для джавы, поэтому с точки зрения академичности там все в порядке.
Не знаю что тебя за гедзь укусил, но очень с тобой не согласен за критику Макарова и кода yii2. Для своей нишы это очень достойный фреймворк. Критиковать его можно было бы и по-легче.
Еще раз спасибо
Для вас это новость? Странно.
Дмитрий последовательно и системно мочит репутацию yii уже годы и годы, делает это изнутри (на профильном форуме). Вот например.
Причем логика у него железная: Yii плохой, нужно Симфони, которая, по его словам, только под малопосещаемые админки, поэтому не подойдет для обычных сайтов, для создания которых yii как раз в основном и применялся.
Основная проблема, что разработчики таких опенсоурс штук, из за маркетинговых и прочих мотивов увы не захотели быть ЧЕСТНЫМИ со своими пользователями и намеренно умалчивают ту правду которая им невыгодна.
А люди в мир этого фреймворка приходят как бы не с багажем знаний магистра программирования Гарварда или опыта 5 лет в Java , приходят php самоучки, и, следуя докам, пишут согласно тому как они интерпретировали объяснение об MVC. И поэтому ошибаются, причем все.
Ну а потом когда понимают как их нае.... становятся хейтить фрейм, мстя. Закономерный результат, поведения команды фреймворка.
Дмитрий по фронтенду планируете что-нибудь? Если в бекенде понятно как абстрагировать свой код от внешнего, то на фронтенде сейчас в любом проекте код зависит от кипы внешних библиотек. Бывает проект еще не успели дописать, а тонна из этих библиотек уже умерла и надо всё переделывать. Например как было с angularjs, когда разработчики решили делать по-сути совершенно новый фреймворк angular. Было проще выбросить весь код на angularjs и начать писать заново на angular, чем пытаться переделать всё это.
Еще любят накрутить 100500 плагинов к какому-нибудь вебпаку или галпу, а когда релизится новая мажорная версия оказывается, что перейти на неё невозможно, так как эти 100500 плагинов её не поддерживают и половина из них уже никогда не будет поддерживать так как были заброшены. Начинается боль. Сборку проекта нужно строить на npm scripts без всяких плагинов, но большинство продолжают крутить эти дурацкие плагины. Ладно еще вебпак тащут в проект, но зачем тащут галп я вообще не понимаю, это набор бесполезных оберток над различными утилитами, от которых никакой пользы, только проблемы.
Зачем? Зачем изобретать велосипед, если он уже существует?
Какой велосипед и где он уже существует?
Извините за вопрос. Собираюсь купить. Сколько уроков уже прошло и живо ли всё?
Прошло 8 уроков. Живо.