index0h, очень хорошо что все знают принцип SRP который простой типа "каждый класс должен одну ответственность", но плохо что никто не знает что такое "ответственность класса". Дело в том что "веб-приложение" = одна ответственность (которая разбивается на действия), так же как и перемножить 2 и 2 - тоже одна ответственность (которая разбивается на стеки и сдвиги).
Любое действие делится на 2, а значит все нарушают SRP, и такой принцип не должен существовать, он слишком обобщенно звучит и путает людей
index0h, скорее валидатору для определенных проверок нужен исполнитель, а исполнителям для действий - нужен валидатор. Другой вопрос что если в исполнителе находятся и проверялки и действия - то получается циклическая зависимость - для действий нужен валидатор, для проверялок - исполнитель. Если разбить их по принципу - проверялки туда, а действия туда есть ощущение что может проблема пропадет.
Возможно то, что требуется динамически бегать в контейнер - это признак что классы нужно поделить.
index0h, в общем я проверю одно решение, оно пока спорное. его смысл в том, чтобы методы проверялки которые не могут требовать зависимости выбросить в один класс, а методы действия - в другие классы, и туда подрубать зависимостью проверялки, а не целые компоненты
index0h, так а для кого мы тогда про конструкторы затираем? мне на статике удобнее будет всё зафасадить, чем рефлексию разбирать... если я не ошибаюсь там поцоны плачут что им тестировать неудобно, поэтому значит архитектура и ебитесь. если статика маст хэв и быстро - то пусть сосут лапу
index0h, лара архитектура чего блин. Задача. Потереться о старых добрых деньках и о том что лара гг можно когда угодно это пустые эмоции. У них пример простой. Когда парсим массив правил создаются обьекты в которые подбрасываются зависимости. Мою проблему они решают тем что создают обьекты в момент проверки. А я зависимости пихаю в обьект, где описаны все правила.
Если в создании на ходу нет ничего плохого тогда архитектура ихняя это каша бесполезная они нарушают ее сами
index0h, понятия не имею что им не удобно там тестировать. Говорят кидай в конструктор, а не задавай колбеки в которых просишь контейнер создать зависимость для тебя
index0h, прочитал твою рекомендацию и все ссылки по ней. В зенде нет проблемы зависимостей т.к. там валидатор напрямую описывает что делать. Если два валидатора используют те же проверки таких примеров нет. В рекомендациях как обычно тыща страниц на тему постановки запятых и размышлений о вечном, и ни одной про зависимости. Я этим рекомендацтям давно следую только чтиво ради чтива мне не помогает. А новичка убивает нафиг.
Коко статический. Рекомендовать его вот это разрывной в ногу всему поколению
Григорий Васильков, тот же лара валидатор вышел из положения так что фаулер бы в гробу перевернулся. Проверяя внутри валидатора конкретное поле, валидатор просит инжектор всего приложения создать ему обьект рулес с зависимостями, где и щашито все что нужно. Получается что заыисимость подрубается в конкретный момент проверки, когда она уже точно есть. Я пытался зависимости сразу же распихать чтобы динамики не было, но получается что отказаться от сервмс локатора невозможно
Мне то оно и не мешает а вот одельным личностям это неудобно тестировать, а в ларе почемуто все правильно как им кажется, потому что лара наверное. То что там так же их не особо печет
Ну задумка такая. Валидатор хранит в себе рулесы в виде методов. Где нужно он подрубается и делает проверку, которая заканчивается кодом сообщения. Для некоторых рулесов нужны сервисы проверяльщики которые нужно внедрить в валидатор. В то же время неуоторые операции проверялок требуют других валидаций. Вот и получается связность которую нельзя разорватт
спасибо ещё раз
Eloquent планируется использовать внутри БДРепозитория, а не везде в проекте. Вокруг него будет квери билдер с возможностью отфильтровать даже массив обьектов.
BoShurik, ознакомился со статьями, первую читал и после неё вопрос и задал
Создание любого кусочка программы представляет собой целый список действий что-ли?
1. обязательно создать файл /config/packages/mymodule.php (в глобальной папке??)
2. создать папку App/Bundle/MyModuleBundle
3. создать файл App/Bundle/MyModuleBundle/MyModuleBundle.php -> метод как-то там ~getExtension()
4. создать файл App/Bundle/MyModuleBundle/DependencyInjection/Configuration.php -> метод getConfigTreeBuilder()
5. создать файл App/Bundle/MyModuleBundle/DependencyInjection/Extension.php -> метод load()
6. создать папку App/Bundle/MyModuleBundle/Services/MyModuleService.php -> собственно какие-то действия, которые потом от модуля будут требоваться
7. создать файл App/Bundle/MyModuleBundle/Resource/config/services.php -> зарегистрировать MyModuleService, который будут существовать в единственном экземпляре. И здесь ли забиндить их на интерфейсы? (App/Bundle/MyModuleBundle/Interfaces/MyModuleInterface.php). Как быть с теми вещами, которые биндятся на интерфейс, но при этом могут быть созданы под каждую задачу снова? Или в этом случае их нет смысла биндить на интерфейс?
8. И в каком-то из этих 7 мест каким-то загадочным образом прокинуть конфигурацию сверху к модулю, чтобы программист мог исправляя единый конфиг менять настройки отдельного модуля, а если в едином конфиге пусто - использовать конфиг самого бандла
Короткий вопрос, блин это всегда так чтоли? Мои ребята (и я) башкой упадут просто не забыть, что это всё нужно иначе оно не взлетит.
BoShurik, я не слишком рассуждаю за архитектуру, не руби с плеча
Ссылки сейчас буду читать, задам вопросы
Я не говорю о том, что оно нужно или не нужно.
Я понимаю что я разбиваю проект на куски, каждый из которых будет делать отдельный человек до тех пор, пока они не понадобятся друг другу. Каждый кусок будет бандлом. Каждый кусок при желании можно вынять и поставить в новую симфони и повесить на отдельный домен.
Это все для того чтобы уменьшить моменты в которых двум разным людям приходится одновременно писать один и тот же файл и потом резолвить что оставить, а что сохранить.
Пусть каждый пишет свой небольшой кусок программы. Даже если этот кусок - забрать из гета "реферал_айди", положить в куки, и сделать редирект, очистив ссылку от реферал_айди. Пусть это будет маленький бандл который человек закончит и подключит потом где нужно, подкинув сервис выполняющий задачу на вход нужного контроллера.
Ну вот я хочу элокуент капсюль, это именно тот самый лоад, о котором мы с тобой говорим. Там нужно создать обьект-менеджер, сохранить его (в будущем это сервис "дб"), в него прокинуть конфиги, поставить галочку "использовать глобально" - чтобы AR-модели подцеплялись к этому "соединению-по-умолчанию", проще говоря если мне потребуется обратиться в базу данных, модуль нужно инициализировать или при старте приложения или при первом обращении к билдеру запросов - но они не предполагают реализацию фабрики, которая создает билдеры и при первом билдере - подключается в базе - они рекомендуют при старте приложения настраивать обьект-соединение, которое подключится в базе когда мы сделаем первый селект.
Опять же - я долго привыкал не использовать текстовые названия для сервисов, а биндить их просто на сам класс или на интерфейс. Тут же весь конфиг так и пестрит тем что я должен обязательно сервису дать имя в дот-нотации, чего? Я зачем отвыкал, тренд был, а теперь кончился?
Таким образом я пытаюсь понять как реализовывать такие вот модули, которые требуют предварительной настройки, пытаюсь понять отличие от ларавеля - где для этого были сервис-провайдеры, отличия от фалкона - где это просто было в php файлах через $di->setShared($interface, $className), или собственного DI где использовались колбэки для того, чтобы получить из $di зависимости и прокинуть их на свои места.
Документация предлагает создать параметр $config, который прокинуть через
->arg('array $config', $config);
но при этом значения этого конфига я хочу прокидывать из вагранта через env() или _более_простым_ способом, а не организовывать генератор кода, который будет что-то там под капотом себе делать, что я потом людям, кто с трудом понимает зачем AR никак не объясню.
Здесь просто немного отличается подход, и я не могу вкурить как именно, а документации на блогах написано "просто напишите services.yml и всё заработает", ни как прокинуть конфиги с верхних слоев вниз - ничего, ни как сделать полностью отдельный модуль, который не знает про внешнее приложение почти ничего - ни слова, все блоги шустрят настройками виртуальных машин и чем угодно кроме такой банальной вещи как я пытаюсь найти