Комментарии 33
Раздел с созданием скелета бандла — спорный. Гораздо проще использовать стандартный composer init, т.к. в вашем случае удалить придется гораздо больше, чем создать. К тому же вы добавляете лишние зависимости (по сути бандл должен зависеть только от symfony/framework-bundle, как минимум symfony/flex, sensio/framework-extra-bundle и symfony/lts — лишние)
Ну а в остальном создание ничем не отличается от других версий Symfony
тем более, что они автоматом ставятся в любой проект, который использует Symfony 4
Речь идет о новых проектах, использующих flex. Если кто-то обновил свое приложение с 3.4 до 4 и захочет поставить ваш бандл, он очень не обрадуется появившемуся flex, который внезапно переопределит все конфиги :)
а вот sensio/framework-extra-bundle тут действительно нужен. Он необходим для роутинга через аннотации.Не рекомендуется использовать такого рода "магию" в бандлах. Равно как и использование автовайринга и автоконфигрирования: Best Practices for Reusable Bundles
Services should not use autowiring or autoconfiguration. Instead, all services should be defined explicitly.
Моё мнение — как удобно, так и делите, другое дело, что бандл не должен быть монструозным и содержать чрезмерное количество разрозненного функционала, это не должен быть мини-монолит, который вы таскаете между проектами.
бандл не должен быть монструозным
Зависит от виртуозности разработчика :) К этому надо стремиться, в этом случае правило unix очень кстати: «сделай мало, но хорошо», главное чтобы не получилось как в npm.
главное чтобы не получилось как в npm
с npm проблема только одна — разработчики npm-а которые… ну я могу долго тут их ругать за то что у них странные приоритеты и странное отношение к понятию lock файл. Но главный их косяк — отсутствие возможностти подписывать пакеты, дабы исключить возможность подмены как это случалось не однократно (что приводило к веселым новостям о том что eslint слил чьито ключи в сеть).
Что до "сделай мало но хорошо" — посмотрите на штуки типа grep, less и т.д. Я не могу сказать что они мало делают. Ну то есть… проблема этого "мало" в том что это относительное понятие и оно для каждого свое.
Суть не в том что бы там чего-то было "мало" или "много" а в том, что бы причины для изменений штуки были одни и те же. Если причины разные — рано или поздно они начнут конфликтовать между собой и придется идти на компромисы. так магенты появляются (там еще избыточное обобщение и неверная стратегия "расширяемости" в стиле вротпресса).
Во вторых на тему разделения проекта на модули (а бандлы это вид модуля) пишут книги еще с 70-х, и все сводится к тому что бы уменьшать связанность между ними и повышать cohesion. Лучше с этими вопросами попробуйте разобраться.
Скажем… типичная проблема людей, которую я наблюдал на проектах — желание разделить на бандлы и потом юзать нутро этих бандлов в других бандлах. Типа есть бандл «пользователи» и во всех остальных бандлах идут отсылки на сущность `User` из этого бандла, хотя в целом достаточно лишь айдишки (хотя логика тут ясна — так намного проще, особенно по началу, в плане выплевывания данных в шаблоны). Ну и всякие CommonBundle, CoreBundle и прочие UtilsBundle свидетельствуют о проблемах с декомпозицией на проекте.
Ну и в заключение — не надо делить проект на бандлы. Вообще. Бандлы нужны для реюза кода между проектами, что бы можно было их подключить к проекту и все. Та же аутентификация или восстановление пароля в целом неплохо обобщаются до бандла, но мне не известны примеры где это сделано хорошо (хотя скажем есть вариант подключить какой AuthN-server и не париться с бандлами, но это больше вообще к вопросу о расширении кругозора к тому как не писать код а юзать готовое).
Если вы хотите разделить проект — сделайте нэймспейс. Этого более чем достаточно.
Я бы наверное сделал бы этот самый общий User.
уменьшать связанность между ними и повышать cohesionВспоминаю модули в magento 2, всегда думал что это не правильно все :)
желание разделить на бандлы и потом юзать нутро этих бандлов в других бандлахПонятно что наследование лучше избежать.
не надо делить проект на бандлы. Вообще. Бандлы нужны для реюза кода между проектами, что бы можно было их подключить к проекту и все
всякие CoreBundleНе понял, можно иметь CoreBundle, только называть так нельзя?
symfony.com/doc/current/best_practices/creating-the-project.html
Я конечно не сторонник там всякой отсебятины и наоборот сторонник все делать по мануалам. И меня немного удивило в одной конторе когда я обнаружил AppKernel там где его наверное никто больше не держит. Но это бесконечное bundle -bundle которое слышишь целый день немного утомляло. Интересно как реальные разработчики восприняли такое новшество. Боюсь что все по привычке держат в бандле да ещё и не в одном
ходят легенды что изначально план был дать возможность людям дробить проекты на кернелы, потому была папка app и src. В этом случае удобно было бы отдельные модули подключать в свои кернелы бандлами и т.д.
Люди неправильно поняли и начали воспринимать бандлы как модули. и дробить проект именно таким образом. Причина для этого очень и очень проста — автоконфигурация. Вы создали папку Entity внутри бандла и доктрина автоматически подтянула оттуда сущности. Вы создали папку Resources и… ну вы поняли идею.
Жить без бандлов вообще можно было в целом с самого начала. Но ключевой момент распространенных заблуждений — автоконфигурация и неудобные конфиги.
С выходом symfony 3.3 по сути конфиги симфони стали куда более удобны для "безбандальной структуры". Но проблема того, что люди структурируют проект под автоконфигурацию, все еще никуда не делась.
что до мануалов — best practice симфони появился с выходом symfony 2.8 вроде, то есть люди уже успели набомбить проектов и привыкнуть. В этом бэст практис покрывался вопрос что нет смысла дробить на бандлы но опять же автоконфигурация а потому "если хотите бандл — не делите ничего а юзайте AppBundle".
В теории можно сделать идеальный проект с двадцаткой бандлов всех мастей которые делают «мало, но хорошо»
еще раз — не надо делить проект на бандлы. Бандлы для реюза кода между проектами, инфраструктура какая-то, обобщенный функционал. Например вам надо быстро прикрутить websockets — ставим centrifugo bundle. Бизнес логики в бандлах быть не должно.
Я считаю что нужно смотреть реалистично.
То есть забить просто и не пытаться даже делать нормально декомпозицию? ну ладно.
Вспоминаю модули в magento 2
магенту это вообще страх и слезы.
Понятно что наследование лучше избежать.
причем тут наследование? В целом когда у вас есть модуль Users и еще десяток и все юзают сущность из этого бедного модуля Users, хотя им только айдишка нужна. И это самый лайтовый пример факапов.
Не понял, можно иметь CoreBundle, только называть так нельзя?
Суть не в названии, вы же это понимаете. Я сейчас говорю о разделении приложения на модули. То есть вы можете сделать какой-нибудь модуль Infrastructure, но там не должно быть сущностей и бизнес логики.
То есть забить просто и не пытаться даже делать нормально декомпозицию? ну ладно.Пытаться нужно, но со здравым смыслом.
Все понятно. Так-то согласен со всем.
но со здравым смыслом.
можете раскрыть мысль? Что значит "со здравым смыслом"?) Мы либо как-то по разному "декомпозицию" понимаем, либо я не знаю.
Мы дискутировали по поводу форка/наследования от 3-party библиотеки. Так вот с универсальным модулем который наверняка останется специфическим для проекта (идеальные крутые вещи ведь не часто получаются), может выйти так что для использования в новом проекте придется или форкать (хе-хе), или переписывать отдельные части, что влечет фикс уже первого проекта. Я это имел ввиду.
Поэтому хороший модуль кэширования или там работу с pdf можно вынести, а вот что-то из бизнес логики я не спешил бы выносить.
P.S. И вообще, я за интерфейсы везде. Чтобы как psr log, только для всего.
я говорил про декомпозицию а не про желание обобщить все и вся. Это разные вещи.
По поводу проблем с "форками" — обычно это как раз таки проблема излишнего обобщения. Маленькие узко специализированные решения с меньшей долей вероятности нужно будет "допиливать", их проще заменять полностью. Увы у большинства философия "запихнем в эту простую штуку все".
только для всего.
Greg Young — Stop Over-Engenering — может быть вам понравится, весело задорно и в целом пересекается с темой нашего разговора.
запихнем в эту простую штуку всеТак это потому что разобрать большое на маленькое стоит больших усилий, по себе знаю. И нет уверенности что усилия окупятся.
И опять же, главное в меру, чтобы при открытии node_modules глаза на лоб не лезли.
И нет уверенности что усилия окупятся.
Ну так может тогда не нужно пытаться делать инструменты общего назначения и обобщать логику так что бы вышла магента? Что бы "для всех подходила". Причем без должной декомпозиции вы рано или поздно упретесь в количество зависимостей.
чтобы при открытии node_modules глаза на лоб не лезли.
Лайфхак — не открывайте их просто. Это нужно очень редко и главное что бы была возможность удостовериться что пакеты никто не подменил (по подписи) и что нет секьюрити ишусов у зависимостей. Сегодня это делается автоматически.
Пошаговое создание бандла для Symfony 4