Redjik
Джедай-мастер
поэтому я приверженец одного конфига на 100500 строчек, но, почему то, попурярная практика их разбивать
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Вопрос по ООП синтаксис
- Автор темы Sanchis
- Дата начала
Вурдалак
Продвинутый новичок
Здесь будут абсолютно те же проблемы, что и с одним большим классом на 100500 строчек: труднее разобраться + регулярные конфликты. Декомпозиция спешит на помощь, нужно лишь договориться как разбивать конфиги, да. Например, по конфигу на пакет. Ещё я разбиваю по типу сервисов: например, подписчики событий в одном, commands в другом и т.д. С событиями, кстати, тоже проще: в Symfony есть негласное правило иметь класс вида FooEvents с константами: тот же find usages позволяет найти подписчиков на событие (если конфиг в виде массива по крайней мере).
Я думаю, что в будущем будет какой-то стандарт конфигов, который позволит IDE иметь автокомплит, навигацию кликом по имени сервиса и т.д. Те же удобства, что и с обычным кодом. Я уже как-то слышал про желание стандартизировать DI-конфиги, вопрос времени, IMHO. Хотя конкретно для Symfony уже наверняка есть какие-то плагины для PhpStorm.
Последнее редактирование:
Absinthe
жожо
Представь, если у тебя весь код был бы в одном файле.
Хотя одного конфига на бандл хватит.
Только вот недавно Фабиен сказал, что все приложение должно быть в одном бандле. Вот этого уже мне не понять: выйдет свалка, если все мегабайты кода держать вместе.
Есть, прекрасно работает, дополнение на уровне идентификаторов сервисов там есть.
Повторю еще раз, подробнее. Проблемы говнокодеров не связаны с инструментом.
Нет соглашений использовать магию вроде $Component->foo при наличии метода getFoo(). Guns don't kill people.
Магия в CComponent имеет конкретные цели: писать $Page->author->name и обеспечить работу поведений.
Писать $Mailer->driver или $Mailer->getDriver() - личное дело. Если кто-то работает с виртуальными полями без phpdoc, это не пистолет виноват, что нога прострелена.
Вурдалак
Продвинутый новичок
Bundle — это связующее звено между приложением и фреймворком. По аналогии с библиотеками, которые обычно разбиты на 2 пакета: сама библиотека (framework agnostic) + bundle (Symfony, Laravel, etc.). Я бы не стал держать код самого приложения в в bundle, потому что это просто неудобно + лишняя зависимость от фреймворка там, где и без этого можно обойтись.
А вот, кстати - если так мелко бить на пакеты, что делать с общими интерфейсами, которые слишком общие, чтобы четко принадлежать какому-то из пакетов?
Вариант по типу laravel/contracts первым приходит в голову, но тоже странноват. По пакету на набор интерфейсов по смыслу - ну не знаю, как то жирновато.
Вариант по типу laravel/contracts первым приходит в голову, но тоже странноват. По пакету на набор интерфейсов по смыслу - ну не знаю, как то жирновато.
Вурдалак
Продвинутый новичок
А PSR-3 не жирновато?
Вурдалак
Продвинутый новичок
Вообще я считаю разумным иметь такой пакет (в данном смысле не namespace, а composer package) в компании, чтобы, во-первых, по возможности не иметь прямые зависимости от внешних библиотек и, во-вторых, иметь какой-то консистентный внутренний API, принятый в команде. Просто типа Acme API package.
Последнее редактирование:
Absinthe
жожо
Бандл - это компонент приложения, привязанный к фреймворку и решающий определенный класс задач. Большинство бандлов не переиспользуются.
Часть бандла - контроллеры, вьюхи, код фронтенда, команды. Имеются описания сервисов. Сам код бизнес-логики в них не зависит от фреймворка (ага, framework agnostic) , но все остальное, что перечислил выше, зависит.
Поэтому вынесение их - идея не очень хорошая. Выносить несколько файлов в отдельный пакет? Лучше это сделать потом, если понадобится использовать их вне пакета ("если", а не "когда"), и отрефакторить.
А какую альтернативу ты предлагаешь? Все 100500 контроллеров, вьюх и т.д. в куче держать? Не смотря на то, что они прекрасно отделяются друг от друга?
Есть бандл ядра приложения, в котором описываются основные пакеты, относящиеся к большинству областей.
Но когда приложение разрастается, хочется, чтобы некоторые пакеты хотели иметь в зависимостях не только ядро, но и часть других пакетов.
Это не очень красиво, наверное, но я не нашел другого способа.
Sub-domain.
Redjik
Джедай-мастер
Сейчас так и получается, но хочется и рыбку съесть и ... =)
То есть, хочется прямо весь subdomain сделать пакетом, но тогда его нельзя будет нормально кастомайзить
Absinthe
жожо
Либо делать это певерх каких-нибудь очень слабосвязанных компонентов, которые точно будет поддерживаться еще много лет без серьезных проблем с BC.
Absinthe
жожо
Почему нельзя? Подключил через композер, добавил в аппкернел, и оно работает.
Только я не вижу смысла выносить это в отдельный пакет композера для непереиспользуемых пакетов.
Переиспользуемые нужно.
Redjik
Джедай-мастер
хз, я вынес в "пакет" Common (на прошлой работе так делали) все базовые интерфейсы...
и как бы, имхо, пофиг, что все остальные пакеты завязаны на Common... это же контракт, почему бы и нет... по этому контракту будут и остальные пакеты идти
Наверное, лучше назвать Vendor/Contracts. Common - это такая штука... Опасная. Из разряда namespace utils, "свалим-ка сюда все, что непонятно куда"