Сам пользуюсь подобной схемой. Все связано именно с плохой работой Docker в Mac, особенно всё что связано с файловой системой. Хотел одно время назад написать статью как настроить тако окружение, хотя может это не секрет на самом деле. Если кратко, то Synching синхронизирует файлы, ssh port binding для пробрасывания портов во все стороны кому как надо, локальный nginx грузит статику локально, остальное грузит с порта из ssh.
Я немного описал выше что использую некий регистр который по входному квери находит хендлер и выполняет запрос, код идентичен вашему единственное что я решил что всегда возвращаю итератор(может быть конечно любой имплементации)
У меня к вам вопрос для чего нужно использовать именно QueryBus? Пока не могу для себя найти что это даёт?
Спасибо понятно, что вы имели в виду. Но я пришёл пока с совместному использованию двух методов для выборки данных.
1) Для простых выборок типа get(id) findBySomeThing(condition, start, length) главное что методы в репозиторий супер простые и их количество должно быть минимально, иначе репозиторий разбухнет и его коде можно будет потеряться.
2) Как написано в комментарии ниже https://habrahabr.ru/post/280512/#comment_8834588 для сложных запросов использую query объёкты они по структуре практически идентичны командам
$query = new SomeQuery();
$iterator = $queryRegister->handle($query)
единственное отличие от команд, что всегда возвращается итератор
Я считаю что использование одних репозитариев приведёт к разбуханию классов но полный отказ от них приведёт к неудобству когда надо найти объект по ид и для этого нужно создавать квери объект.
Хмм кажется вы представляете о чём я говорю -).
Есть у вас возможность написать как в коде у вас это выглядит потому что у меня я в проекте как раз имеются Query объекты, но я почему-то был зациклен что они работают с хранилищем.
Может сделаете пример взаимодействия Command и Query мне кажется это довольно сильно дополнило бы статью?
Было бы неплохо увидеть два типа Query один для работы с базой, а другой например нечто абстрактное.
Заранее благодарен.
Недавно столкнулся с подобной проблемой т.е. вынесение логики в отдельные независимые классы так же пробывал подход с командами, но меня ни как не устраивало в данном паттерне, то что он не возвращает значение. Может вы мне подскажите как бы вы решили проблемы с которыми я столкнулся так как я ещё пока на распутье.
Первое мое требование было однообразие в архитектуре проекта т.е. некие большие действия должны хранится и вызываться однотипно чтобы примерно знать где искать что и как работает. Это требование отлично ложится под данный паттерн.
Второе иметь возможность комбинировать действия между друг другом, а в это моменте проблема так как данный паттерн не позволяет возвращать значения.
Например:
Пусть будет 2 варианта генерации рекламной компании, которые мы знаем. Плюс нам известно что скорей всего будет другие типы очень похожие. Я немного упрощу задачу, но попытаюсь объяснить проблемы.
Тип 1: генерация состоит из нескольких шагов
Входные данные
Генерация слов на основе удалённого сервиса(те тут не просто функция из 10-20 строчек тут весьма большой и цельный процесс, где вызывает REST API, фильтрация слов по некому справочнику с использование Apache Solr и тд)
Создание рекламных блоков например текстовые блоки
Тип 2:
Входные данные другой источник
Обработка данных например выкидывание чего либо
Генерация слов(тоже самое что и тип 1)
Создание рекламных блоков например картинок
Те мы тут имеем одинаковый процесс генерации слов и подобных процессов будет/есть много причём не только связанных с созданием компании.
Имея команду генерации слов я не как не смогу с ними дальше работать так как нет возвращаемого результат
Под каждый процесс создавать некий сервис c одной функцией тогда теряется однообразность и возрастает сложность поиска где что хранится типа KeywordGenerator или KeywordManger или KeywordHandler…
Иметь KeywordService где будет 100500 функций совсем плохо
Сейчас я сделал некий симбиоз паттерна команда и просто сервисов хранящихся в контейнере те сервисы имеют одну функция у функции один агрумент как в паттерне но есть возможность возвращать значения назвал я эти сервисы Activity :)
Но как было замечено в статье внутренний перфекционист негодует так как нет чётких ограничение кроме устных и нет единой точки вызова сервисов они ижектятся где нужно и плюс изобретён велосипед паттерна.
У меня к вам вопрос для чего нужно использовать именно QueryBus? Пока не могу для себя найти что это даёт?
1) Для простых выборок типа get(id) findBySomeThing(condition, start, length) главное что методы в репозиторий супер простые и их количество должно быть минимально, иначе репозиторий разбухнет и его коде можно будет потеряться.
2) Как написано в комментарии ниже https://habrahabr.ru/post/280512/#comment_8834588 для сложных запросов использую query объёкты они по структуре практически идентичны командам
$query = new SomeQuery();
$iterator = $queryRegister->handle($query)
единственное отличие от команд, что всегда возвращается итератор
Я считаю что использование одних репозитариев приведёт к разбуханию классов но полный отказ от них приведёт к неудобству когда надо найти объект по ид и для этого нужно создавать квери объект.
Есть у вас возможность написать как в коде у вас это выглядит потому что у меня я в проекте как раз имеются Query объекты, но я почему-то был зациклен что они работают с хранилищем.
Может сделаете пример взаимодействия Command и Query мне кажется это довольно сильно дополнило бы статью?
Было бы неплохо увидеть два типа Query один для работы с базой, а другой например нечто абстрактное.
Заранее благодарен.
Первое мое требование было однообразие в архитектуре проекта т.е. некие большие действия должны хранится и вызываться однотипно чтобы примерно знать где искать что и как работает. Это требование отлично ложится под данный паттерн.
Второе иметь возможность комбинировать действия между друг другом, а в это моменте проблема так как данный паттерн не позволяет возвращать значения.
Например:
Пусть будет 2 варианта генерации рекламной компании, которые мы знаем. Плюс нам известно что скорей всего будет другие типы очень похожие. Я немного упрощу задачу, но попытаюсь объяснить проблемы.
Тип 1: генерация состоит из нескольких шагов
Входные данные
Генерация слов на основе удалённого сервиса(те тут не просто функция из 10-20 строчек тут весьма большой и цельный процесс, где вызывает REST API, фильтрация слов по некому справочнику с использование Apache Solr и тд)
Создание рекламных блоков например текстовые блоки
Тип 2:
Входные данные другой источник
Обработка данных например выкидывание чего либо
Генерация слов(тоже самое что и тип 1)
Создание рекламных блоков например картинок
Те мы тут имеем одинаковый процесс генерации слов и подобных процессов будет/есть много причём не только связанных с созданием компании.
Имея команду генерации слов я не как не смогу с ними дальше работать так как нет возвращаемого результат
Под каждый процесс создавать некий сервис c одной функцией тогда теряется однообразность и возрастает сложность поиска где что хранится типа KeywordGenerator или KeywordManger или KeywordHandler…
Иметь KeywordService где будет 100500 функций совсем плохо
Сейчас я сделал некий симбиоз паттерна команда и просто сервисов хранящихся в контейнере те сервисы имеют одну функция у функции один агрумент как в паттерне но есть возможность возвращать значения назвал я эти сервисы Activity :)
Но как было замечено в статье внутренний перфекционист негодует так как нет чётких ограничение кроме устных и нет единой точки вызова сервисов они ижектятся где нужно и плюс изобретён велосипед паттерна.