Yii Framework

она будет. вы же сделаете $x->add($y); дальше orm при сохранении сама все разрулит. Двойная связь ни к чему. В вашем случае пришел id Y, по нему сразу нашли агрегат X, и дальше с ним работаете. Спасибо, тогда немного конкретики, как это сделать в доктрине? судя по докам только как One-To-Many, Unid...

Спасибо за ответ. Скорее всего не нужно в Y onwerId. Сам факт нахождения в аггрегате на это указывает Не уверен что можно обойтись без какой либо ссылки на owner, ведь зачастую нам надо будет получить аггрегат зная только id Y. Например в сервис приложения приходит реквест на update y, наши действия...

Есть аггрегат пусть будет класс X, он содержит коллекцию сущностей Y. Требуется реализовать перенос сущности Y из одного экземпляра X в другой X. При этом перед переносом нужно проверить ряд параметров, тк Y'у может быть запрещен переход в контекст нового X. Примерный код: class X { public function ...

eval?
Если есть желание можете реализовать преобразование к обратной польской нотации, затем вычисление на стеке. (это то что Я делал, думаю вариантов куча)

maleks писал(а): ↑2017.12.21, 11:32 И еще, как вы думаете, зачем они вот эти

Могу только предположить что autowire в yii не поддерживался, когда писался этот код

Думаю если вы делаете по DDD то как оно хранится в бд это последние о чем надо задумываться)
В книгах думаю это реализованно было бы как-то так, VO Money имеет ссылку на VO currency, по типу
Ну или просто у Money были бы эти поля.

Подсчет стоимости корзины это где? если в домене, то там никаких viewModel и не может быть. View model это как способ удобно передать данные во вьюшку.

В ActiveRecord нельзя передавать зависимости через конструтор, можно в сам метод передавать сервис Думаю можно, переопределив instantiate предварительно. Тогда для обычного вывода цены товара на странице, придется во view передавать с товаром и сервис, а потом вызывать ->getPrice($service)? Так мож...

ну не знаю, как мне кажется, тут операция одна, соответственно и сервис должен быть один. Но сами вверху написали 2 операции :) Если дублировать сервис, как по мне не очень хорошая идея т.к. там же может быть разная другая логика. Например пересчитать каунтер для постов категории изменить дату акти...

Ну почему не выкинуть, спокойно выкидывается. Использовать вместо Yii AR можно все что угодно. Но я пользуюсь имеено Yii AR, но не так, как в большинстве примеров. Нашел для себя удобный подход, и вы ищите то что вам удобно, пробуйте. Ну я хотел сказать что AR часть фреймворка, все равно ведь будет...

в связке angular 2-4 + lite-server - фронт/php бэк решал такие проблемы через прокси-мидлварю, которая перенаправляла запрос на сервер, как то так (в конфигах lite-server): "middleware": { "1": proxyMiddleware('/api', { target: 'http://backend.api', changeOrigin: true, pathRewrit...

Создайте 2 формы, у вас же по описанию их 2. 2 экшена = 2 юз-кейса = 2 сервиса = 2 формы (вернее 2 команды но у вас видимо команда = форма). Интерфейс для команды помойму явно излишество.

Если используете yii то имхо проще статистику и подобные read вещи делать как раз на ар. Смысл в доктрине если у вас полностью анемичная модель и практически нет бизнес логики в условиях круда. К тому же AR из Yii не выкинуть, так почему его не использовать в подходящих случаях?

Еще вопрос в догонку по шине возник (взял tactician если это имеет значение) Что если я хочу применить мидлварю не ко всем обработчикам команд (к примеру логирование)? Я вижу несколько вариантов: 1) вместо мидлвари - декорировать обработчик, но я написал удобный (как по мне) локатор - заменяем Comma...

Спасибо за ответ Затем публикуется другим процессом Думаю тоже к этому прийдем, но видимо со временем. Для репликации из MySQL в Tarantool есть низкоуровневые решения Для нас не подходит, например создание одной записи в таблице мускуля может затронуть сразу кучу спейсов, да и тоже удаление сущности...

Ясно, спасибо!

Одиночные команды, используем 2 обертки над обработчиком?

Спасибо.

zelenin писал(а): ↑2017.10.27, 14:14 Да, я вижу вы не только на словах перепутали команду.

Да так и есть)

Еще вопрос как тогда выглядеть будет эта ситуация когда мне не нужна транзакционность? Просто используем другой eventManager?

хэндлер все равно не знает о декораторе. какая причина давать ему это знание, вынося событие из хэндлера? Причина в том что обработать подобное событие (когда обработчик события обратится к read базе данных) необходимо после транзакции. То есть после того как команда обработается. Как вариант сохра...

в смысле у вас самовыполняемая команда?) Имелся ввиду обработчик, извиняюсь) используем термины command для обработчика и request для команды. То есть command по сути сервис для 1го юз кейса. ваша команда не знает о транзакции. Опять же извиняюсь за напутанную терминологию. Используем декоратор на ...