про сеттеры и геттеры накидывать наверное бесполезно

еще хз че в этом году будет на конфе

было б збс если б nikic привезли

или jpauli

ребята, такой вопрос. Есть сущность Database, которая представляет базу данных, которую можно сдампить и восстановить из дампа, причём в полях сохраняется информация вроде даты последнего восстановления после dump или import. Хочется юзать что-то вроде $db->import($pathToDump) и $db->dump($pathToDump). Нужно ли в таком случае передавать в методы объект, который действительно будет делать работу с базой и файлами? Или создавать отдельный объект, который будет вызывать эти методы и делать работу с файлами?

Вот с мейлером хорошая аналогия была приведена, где $mailer->send(email) более предпочтительно, чем email->send. По той же причине $dbManager->import, более предпочтительно чем entity->import. Емейл не должен знать о способах его доставки, так же и сущность базы данных - это только модель и как раз по solid, тоже тут уже озвученному, а вернее по принципу "S", ее н особо должно волновать способы ее импорта/экспорта

сервис - тоже просто объект... и если я не вижу ничего плохого в том что бы засунуть сущность в сущность, то и сервис в сущность засунуть не проблема по идее....

По моему мнению не стоит сущности крестить с зависимостями, выходящими за зону модели данных. Все по тойже причине что и мейлер должен работать с моделью письма, а не наоборот. В сущностях могу помещать дополнительные методы для обработки каких то несложных бизнес правил, но только до тех пор, пока эта логика не требует внешних зависимостей(сервисов)

и какой у email интерфейс?

у email.send() очевиден

если я в методах сущности вызываю new Process(...) или new \PDO(...) это тоже беда?

в методах executeCommand и connectToDatabase

app->execCommand('rm -rf var/log'); app->connectToDatabase()->query('show full processlist');

когда я увидел иньекцию сервисов через дабл диспатч в экшены, то подумал что это безумие

а щас перевожу на них все и кажется не таким уж и плохим

обычно контроллер имеет какие-то общие зависимости для всех экшнов

такие идут в конструктор

частные - через аргументы

Так а экшены и сущности это всетакиж две разные вещи

если я в методах сущности вызываю new Process(...) или new \PDO(...) это тоже беда?

Тут на вкус и цвет конечно, но думаю вот как раз SOLID и хорошо объясняет почему такой подход "с душком"

Всем привет! А есть возможность использовать easyadminbundle для сторонних баз, без энтити. Использовать dbal и т.д.

обычно контроллер имеет какие-то общие зависимости для всех экшнов

так можно скрыть тот факт что зависимостей 10+, 5 в конструктор, 5 в аргументы и вроде как ниче.. а по факту хреново

Пример: есть vps1 с базой.

в конструктор отдаю то что нельзя автовайрингом сделать

так можно скрыть тот факт что зависимостей 10+, 5 в конструктор, 5 в аргументы и вроде как ниче.. а по факту хреново

Почему скрыть?

В use все видно

в конструктор отдаю то что нельзя автовайрингом сделать

Кстати, а для экшнов нельзя указать конкретные сервисы для инжекта?

можно, но это будет очередной $this->get(...)

от которого я пытаюсь уйти

Ну или параметры

Да и зачем следить за зависимостями в контроллерах?

я вот сижу щас смотрю на контроллер у которого 18 зависимостей в аргументах

В пределах одного экшна, да

это не считая всяких твигов и прочего)

Вот с мейлером хорошая аналогия была приведена, где $mailer->send(email) более предпочтительно, чем email->send. По той же причине $dbManager->import, более предпочтительно чем entity->import. Емейл не должен знать о способах его доставки, так же и сущность базы данных - это только модель и как раз по solid, тоже тут уже озвученному, а вернее по принципу "S", ее н особо должно волновать способы ее импорта/экспорта

Можно простую аналогию привести: конверт с письмом сам себя отправить не может — его может отправить только почтовое отделение. Поэтому письмо должно быть каким-нибудь value object'ом, а мейлер — сервисом, реализующим интерфейс мейлера

http://symfony.com/blog/new-in-symfony-4-1-invokable-event-listeners

Можно простую аналогию привести: конверт с письмом сам себя отправить не может — его может отправить только почтовое отделение. Поэтому письмо должно быть каким-нибудь value object'ом, а мейлер — сервисом, реализующим интерфейс мейлера

Каким понятием из предметной области, должно быть письмо?

Каким понятием из предметной области, должно быть письмо?

Да самый обычный конверт с письмом же

У него есть только свойства кому, куда, содержимое и т.п.

Да, что-то я с утра не понял ))

Можно простую аналогию привести: конверт с письмом сам себя отправить не может — его может отправить только почтовое отделение. Поэтому письмо должно быть каким-нибудь value object'ом, а мейлер — сервисом, реализующим интерфейс мейлера

+++ полностью согласен

без единого публичного сервиса собирается контейнер

инлайнит он конечно жестко

При установке phpunit через flex нет самого phpunit, когда добавляешь в зависимость сам пакет, flex пишет мол удалите и установите через flex. wtf?

Подскажите пожаулйста, как можно автоматически сделать доступным https://github.com/thephpleague/tactician-bundle во всех контроллерах, а так же как динамически связывать commands и их handler, потому что в сервисе уже более 200+ комманд, и их становиться сложно поддерживать.

так как каждый раз прописываю такое

# Register TacticianCommandBus Handlers for Commands to Bus app.handler.createuserbuscommandhandler: class: App\Handler\CreateUserBusCommandHandler tags: [{name: tactician.handler, command: App\Command\CreateUserBusCommand, typehints: true}] autowire: true #Register Controllers where Command Bus service will be injected App\Controller\RegistrationController: arguments: - '@tactician.commandbus.default' calls: - [setContainer, ['@service_container']]

Выходит довольно громоздко

Выходит довольно громоздко

Compiler Pass'ы должны помочь

Скажите пожалуйста, это что "Compiler Pass'ы"?

Во время сборки контейнера отрабатывают

Загугли, в доке есть

Они автоматом могут проставлять тэги, например

https://symfony.com/doc/master/service_container/compiler_passes.html

# Register TacticianCommandBus Handlers for Commands to Bus app.handler.createuserbuscommandhandler: class: App\Handler\CreateUserBusCommandHandler tags: [{name: tactician.handler, command: App\Command\CreateUserBusCommand, typehints: true}] autowire: true #Register Controllers where Command Bus service will be injected App\Controller\RegistrationController: arguments: - '@tactician.commandbus.default' calls: - [setContainer, ['@service_container']]

ну с контроллерами простыни легко убрать — autoconfigure + autowire в defaults должны помочь, а вот с регистрацией хендлеров нужно будет писать compiler pass для генерации command на основе имени класса хэндлера

@andrewkovalyov _defaults: autowire: true autoconfigure: true public: false А в контроллерах

И если убрать из сервисов передачу ComandBus для каждого контроллера, будет везде выдавать ошибки

Cannot autowire service RegistrationController": argument "$commandBus" of method "__construct()" references class "League\Tactician\CommandBus" but no such service exists. It cannot be auto-registered because it is from a different root namespace.

Cannot autowire service RegistrationController": argument "$commandBus" of method "__construct()" references class "League\Tactician\CommandBus" but no such service exists. It cannot be auto-registered because it is from a different root namespace.

а какой класс является сервисом @tactician.commandbus.default ?

CommandBus

namespace League\Tactician;

class CommandBus {

Symfony 4.0.3

CommandBus

посмотри лучше через debug:container, у тебя эксепшн говорит прямо противоположное

а, еще вариант может быть с порядком подключения бандлов — твой appbundle должен быть подключен позже этого iirc

1 - я перенес бандл в самый низ списка <?php return [ Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true], .... League\Tactician\Bundle\TacticianBundle::class => ['all' => true], ] 2 - пришлось временно убрать из конструктора CommandBus что бы выполнить комманду debug:container В поле "Class name" нет ссылки на CommandBus class, а значит, он не зарегестрирован Так же попробовал сделать debug:container log, всего 51 алиас на сервисы, CommandBus нет в списке.

ERROR: S client not available

хееей

там ведь есть другой тип хендлеров

смотри доку можно настроить их так, что команда будет выбираться по тайпхинту методов в хендлере

и тогда надо будет регистрировать только сами хендлеры + давать им теги

да я читал, у меня не работает

вроде такого?\

# Register TacticianCommandBus Handlers for Commands to Bus app.handler.createuserbuscommandhandler: class: App\Handler\CreateUserBusCommandHandler tags: [{name: tactician.handler, command: App\Command\CreateUserBusCommand}] autowire: true

Ребята, вопрос слегка по менеджменту. Когда аналитик лезет в базу данных и начинает продумывать таблицы и ключи - это типа data driven programming?

И как вообще возможно жить с data driven programming-ом (если оно так называется конечно)

# Register TacticianCommandBus Handlers for Commands to Bus app.handler.createuserbuscommandhandler: class: App\Handler\CreateUserBusCommandHandler tags: [{name: tactician.handler, command: App\Command\CreateUserBusCommand}] autowire: true

нет

tags:       - { name: tactician.handler, typehints: true }

Когда ты пишешь сущности и т.п. Не делать же экспорт в код из базы данных

Отсюда ощущение, что data-driven-programming (...) старое говно, а анал долбоебан

@thatside так ведь все-равно в сервисах много комманд)

и хендлер такого типа public function createClientInvoice(CreateClientInvoice $command) при этом его имя любое, важен тайпхинт

А когда аналитик стал DBA?

Как такового DBA нету просто

Допустим даже есть DBA

Как с этим жить-то?

у меня в сервисах команды не упоминаются, только хендлеры но ведь ты можешь сделать вообще автоконфигурацию и использовать resource и регистрировать их все в папке как сервис с заданными тегами

Как такового DBA нету просто

Ему эти таблицы и ключи зачем нужны? Если для аналитики, как вариант ты ему можешь строить отдельную базу-проекцию основной и пусть там веселится

@thatside так ведь все-равно в сервисах много комманд)

а, или тебе нужно, чтобы команды тоже имели доступ к контейнеру?

@thatside Что то вроде такого я и пытаюсь сделать, авторегистрацию комманд и их хендлеров, и что б каждый раз не надо было регестрировать контроллер и передавать туда '@tactician.commandbus.default'

Смысл в том, что сейчас он ответственный* за новый функционал и уже создал таблицы и требует, чтобы в базе все так и было

@thatside сейчас я вынужден регестрировать каждый раз команду в сервисах и делать ей тайпхинт для ее хендлера. А еще, вынужден регестрировать каждый контроллер и пердавать туда '@tactician.commandbus.default'

что - то у тебя странно вообще...

Есть ли такое вообще, что изначально чувак (анал или DBA или еще кто-то) делает таблицу, а вы потом делаете из всего этого говна сущности?

Просто ладно бы я писал SQL скриптики

Так у меня ж доктринка, мне че, SQL + RSM теперь юзать

@thatside и вышло у меня очень много сервисов, только для ComandBus

@thatside сейчас я вынужден регестрировать каждый раз команду в сервисах и делать ей тайпхинт для ее хендлера. А еще, вынужден регестрировать каждый контроллер и пердавать туда '@tactician.commandbus.default'

MyBundle\Controller\:     resource: '../../Controller/*'     autowire: true     tags: ['controller.service_arguments']