Р
Чтобы потом не получить "идея подтвердилась, на базе этого уг срочно допиливаем n тысяч фич"
Size: a a a
2020 September 23
VS
Писать тесты наверное не буду, так как от меня потребуется только накидать рабочий черновик проекта, может выкинут проект и начнут с нуля если там правок получится больше. Поэтому спросил, а так все сделать в виде толстого контроллера то думаю это быстрее для рабочего MVP
Да может толстые контроллеры + хелперы(утилсы) = лучшее в твоей ситуации.
D
ваша идея тоже вполне про command/handler . Тупо декомпозиция кода будет. Реквест- контроллер, логика - хэндлер, запросы - репозиторий. Но попписать подольше надо будет чутка.
Это единственное что пришло в голову, а все эти cqrs, ddd я не осилю да и на данном этапе кажется и тесты не потребуются
VS
Vlad Sobenko
Да может толстые контроллеры + хелперы(утилсы) = лучшее в твоей ситуации.
Потом появится команда, уже будете решать куда и как двигаться
VS
Это единственное что пришло в голову, а все эти cqrs, ddd я не осилю да и на данном этапе кажется и тесты не потребуются
command/handler - это половина cqrs ))
VS
бери symfony messenger и клепай команды и хэнлеры
AD
ПГ
Это единственное что пришло в голову, а все эти cqrs, ddd я не осилю да и на данном этапе кажется и тесты не потребуются
Ну еще проще: это вместо хэндлеров Service (по 1 на каждую сущность, агрегат) использовать, а в качестве агрументов массив(это уже не очень, но зато избавляет от создания DTO/Command, но теряется автокоплит :( ). А уж потом можно и DTO накинуть. Так вы отделяете логику из контроллера + практически нет оверхеда. Гавнецо есть, но зато + скорость. Тем более у вас прототип, причем небольшой
D
Ну еще проще: это вместо хэндлеров Service (по 1 на каждую сущность, агрегат) использовать, а в качестве агрументов массив(это уже не очень, но зато избавляет от создания DTO/Command, но теряется автокоплит :( ). А уж потом можно и DTO накинуть. Так вы отделяете логику из контроллера + практически нет оверхеда. Гавнецо есть, но зато + скорость. Тем более у вас прототип, причем небольшой
Массив зачем? Прошу простить просто не догоняю
ПГ
Массив зачем? Прошу простить просто не догоняю
вместо команд. Совсем гавнецо + теоряется автокомплит, наверное профита даже в скорости не будет и валидацию не навесить. Лучше наверное dto/command
AD
вместо команд. Совсем гавнецо + теоряется автокомплит, наверное профита даже в скорости не будет и валидацию не навесить. Лучше наверное dto/command
Можно попрощатся с автоматическим поиском handler по команде и морочится с DI конфигурацией
ПГ
Можно попрощатся с автоматическим поиском handler по команде и морочится с DI конфигурацией
Не понял. Зачем DI для массива?
AD
Не понял. Зачем DI для массива?
handler
ПГ
handler
Зачем, зависимости подгружается в конструктор, а массив в метод.
AD
Зачем, зависимости подгружается в конструктор, а массив в метод.
interface HandlerInterface {
public function handle(array $input): void
}
class OneController {
private HandlerInterface $handler;
//construct
public function __invoke() {
$this->handler->handle(['message' => 'hello world']);
}
}
class TwoController {
private HandlerInterface $handler;
//construct
public function __invoke() {
$this->handler->handle(['email' => 'admin@my.google.cloud']);
}
}
Как будет выглядеть DI конфиг?