Философия 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. За этим приходится следить самому.

А с фреймворком без фасадов и со строгим шаблонизатором такие пункты не нужно вообще придумывать, так как там это невозможно из коробки.

Ответить

 

Serg

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

Ответить

 

Mx

у нас там вот такие пункты

Огласите весь список, пожалуйста! ©

Ответить

 

Григорий

Отличное видео! Очень много полезных моментов разобрано!

Ответить

 

Павел

Посмотрел на одном дыхании, спасибо!

Я планирую приобрести мастер-класс и большую часть видео планирую смотреть в записи так как по субботам вечером не всегда будет получаться.
Дмитрий, дальнейшие видео так же будут редактироваться перед публикацией как и это?
Отредактированный материал мной лучше воспринимается:)

Ответить

 

Дмитрий Елисеев

Да, будет.

Ответить

 

Adel

Создалось впечатление (разумееется, ложное) будто симфони-проекты по умолчанию прекрасно написаны и не подвержены ошибкам )

Также как везде, люди имплементят бизнес логику в life cycle эвентах (не всегда для этого нужен реквест), юзают доктрину как актив рекорд, не пользуются доменными эвентами.

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

Ответить

 

Андрей

Дмитрий, спасибо за доклад!
И спасибо за таймкоды в описании )

Ответить

Оставить комментарий

Войти | Завести аккаунт


(никто не увидит)



Можно использовать теги <p> <ul> <li> <b> <i> <a> <pre>