Не могу понять, где и как лучше разместить провайдеры?
С вендорными удобно, так как они все лежат в vendor имея отдельную директорию на каждый провайдер, а вот когда пишешь свои провайдеры, которые в последующем надеешься переиспользовать все становится более туманно.
Можно размещать в AppBundle/Provider/ProviderName.php, но в этом случае один провайдер — один файл, а ведь может понадобится множество файлов.
Если надо множется файлов, то Namespace получается AppBundle/Provider/ProviderName/ProviderName, валидно ли это?
Далее, Symfony Best Practice говорит нам размещать загрузку конфигураций в AppBundle/DependencyInjection, для этого Silex'у тоже потребуется отдельный провайдер. Как быть?
Кратко: Как, следуя Best Practice, упорядочить расположение провайдеров в Silex?
UPD: Буду очень благодарен, если скинете интересные и красивые, в плане архитектуры, Silex проекты.
Ну вот пишите вы какой-то компонент, и бац, у вас появляется нэймспейс с этим компонентом. А потом пишите вы такой провайдер, а он так бац и в неймспейсе компонента, для которого вы это дело пишите. Или у вас просто есть нэймспейс Provider.... Ну думаю вы меня поняли. Если у вас там провайдеров слишком много - стоит тогда подумать почему так.
Сергей Протько: Собственно, что бы иметь возможность переиспользовать какую либо часть. К тому же, это позволяет разделять код на маленькие части, для удобства работы над ним.
Один из таких провайдеров, к примеру, ConfigServiceProvider.
Как я понял, сама идея Silex иметь провайдер на каждый "чих".
Flaker: ну вот у вас компонент по работе с конфигурацией. И еще какой компонент. Что до провайдеров - каждый реюзабельных чих. Тут как с бандлами для симфони, они должны быть по возможности независимы, а некоторые делят одно приложение на десяток бандлов и радуются.
Flaker: вопрос терминологии. В более общем смысле это компонент. Провайдер это штука, которая позволяет зарегистрировать части компонента в pimple и только.
Сергей Протько: В статье в расширении Silex есть код, который расширяет routes: "$app->extend('routes'...". Держать это в bootstrap файле не самое лучшее решение. Где держать такие вещи?
Flaker: собственно... там же в статье предлагается это дело держать в yaml файликах, я так и делал пока не осознал что для чего-то сложнее двух трех экшенов мне проще взять Symfony, ибо количество бойлерплейта делает такие приключения не выгодными.
Flaker: компоненты Symfony и так используются в silex, просто в Symfony именно как фреймворке, а не как в наборе компонентов, уже предусмотрен весь тот бойлерплейт, который необходим.
Если же вы хорошо понимаете что вы делаете и почему, то можно попробовать сделать что-то свое (ибо меня лично дефолтная ситукрута симфони уже не устраивает), тогда можно взять silex, выкинуть из него pimple и вставить например php-di. А на базе этого уже делать нормальную подгрузку конфигов и т.д.
Сергей Протько: Про php-di не знал, спасибо! Посмотрел, очень интересная штука. Полноценный DI контейнер, и правда "for humans". Там в примерах к нему на GitHub неплохой пример с FastRoute, интересно, как они вместе по производительности... Наверное, не хуже Silex. Где бы бенчмарки найти.
Flaker: FastRoute к слову не самая быстрая реализация раутера) Никита, автор этой библиотеки, уже не раз сокрушался что зря так ее назвал. Там просто довольно эффективно используются регулярные выражения, но уже не раз обсуждалось что можно сделать еще быстрее.
Flaker: охох, ircmaxell как-то написал статейку про один из вариантов реализаци, только как пруф-оф-концепт и на рэддите это дело обсуждалось, там собственно и был спор по поводу того что fastroute просто так называется, он очень быстр но можно сделать и быстрее. blog.ircmaxell.com/2015/05/prefix-trees-and-parser...
Средний
