Вот такого интерфейса достаточно, не нужно городить TResult, команда не должна ничего возвращать. Если нужно получать данные (например, идентификатор созданной сущности), то это делается двумя путями:

1. хороший: через отдельное событие, на которое клиент подписывается, так как команда может выполнится асинхронно
2. средненькой паршивости: записывать данные прям в объект переданной команды.

но что-то там возвращать -- совсем плохо.

fkthatlove_bach,

И как это с IoC связано?

Напрямую.

love_bachдля регистрации в IoC - норм?

здесь нет никакого маркерного интерфейса, не нужен он.
рефлексия позволяет найти все реализации по дженерик-интерфейсу.

fkthathVosttНапрямую.

hVosttрефлексия позволяет найти все реализации по дженерик-интерфейсу.
Сам сказал, сам опроверг.

тут нет маркерного интерфейса, который используется только для регистрации зависимостей.

fkthathVosttкоманда не должна ничего возвращать.
Что за горячечный бред? Метод тоже никогда не должен ничего возвращать? Откуда тут знать, что ТС подразумевает в данном случае под "командой".

почитай про ДДД. возврат значения из команды -- антипаттерн.

CQRS точнее

fkthathVosttCQRS точнее
В исходной теме где-то было про CQRS?

я так понял, что речь идёт про реализацию команд хендлера из паттерна CQRS

ничего другого не было сказано, так что я не понимаю с чем ты тогда споришь, да её со слюнями про "горячечный бред" :)

love_bachне по теме сабжа вопрос:
1. а почему плохо? можешь пример привести?
2. "так как команда может выполнится асинхронно" - await?

1. потому что команда может быть выполнена отложено, и результат будет позже. на начальном и даже среднем этапе разработки это не так очевидно, вылазит гораздо позже.

2. async в данном случае это для взаимодействия с асинхронными интерфейсами (апи, бд, файловая система, и т.п.), но на то то и команда, что может встать в очередь выполнения, или это может быть тяжёлая операция, которую не стоит ожидать.

в случае обязательного типа ответа, придётся городить костыли, что-то типа "пустое значение", так как void нельзя указывать в качестве типа. и на лицо кривой интерфейс.

love_bachя так понял, что это все в "асинхронное взаимодействие" мотивировано. а если его нет, то вдруг оно появится

Нет, мотивировано не этим, это просто один из вариантов развития.
Команда это не функция -- вот основное отличие. Наличие возможности возвращать результат неизбежно приводит к тому, что команды начинают применять, как функции, что вредит архитектурному принципу.

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

Если приводить аналогию с SQL, то это как INSERT/UPDATE/DELETE -- каких вы результатов ожидаете?
Единственное противоречие, которое не бьётся с командой, это идентификатор, который вычисляется на стороне БД при вставке записи в таблицу.

Как решается, я писал выше.

fkthathVosttв случае обязательного типа ответа, придётся городить костыли, что-то типа "пустое значение", так как void нельзя указывать в качестве типа. и на лицо кривой интерфейс.
Ну, можно ведь просто два интерфейса сделать. ICommandHandler<TCommand, TResult> и ICommandHandler<TCommand> - такое сплошь и рядом. Для Task тоже два типа определены.

Этого не достаточно.
Придётся сделать 2 метода у ICommandBus
Придётся сделать 2 интерфейса для самой команды.

Всё станет сложнее минимум в 2 раза. На самом деле более, чем в 2 раза.

love_bach,

что именно из команд вы хотите возвращать?
айдишник созданной записи? что ещё?

love_bach,

если команда у вас что-то достаёт/вычисляет/преобразовывает и вы хотите это куда-то передать/отобразить, то вы неправильно используете концепцию команд и неизбежно наполучаете граблями по лбу и по заднему место, больно :)

fkthathVosttчто именно из команд вы хотите возвращать?
айдишник созданной записи? что ещё?
Мы когда-то пришли к идее использовать пару айдишек - один автоинкрементный для БД, второй "внешний" guid, который генерится сразу в приложении еще до вставки записи.

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

love_bachпросто интересно - если бы ну вот сильно сильно надо было , то как?

в идеале, подписываться на события, которые генерит команда.
два варианта подписки:
1. постоянная подписка, логика отдельно, хорошо.
2. разовая подписка на изменение, тогда командам хорошо бы иметь свои ид-шники, приемлимое решение

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

love_bachlove_bachвынести эту нормализацию из команды?

точно!
бл*, она еще и в валидаторах, типа если могу - нормализирую.
придется и это еще исправить

да, отличная идея :)

fkthathVosttтогда можно было и отказаться от автоинкремента и просто сделать свой гуид примари
Гуид примари для кластерного индекса это не очень хорошо, потому что он не sequential и это сильно тормозит вставку. Тут разве что если генерить последовательные гуиды (в сиквеле есть готовая ф-ия, на клиенте немного сложнее, но вполне решаемо). Но, собственно, пара айдишек на деле совсем не напрягает, тем более у нас эти "внешние" guid-ы почти везде используются только для корней агрегатов.

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

fkthat,

недавно была дискуссия https://www.sql.ru/forum/1287606/vnyatno-obyasnit-pochemu-klasterizovannyy-indeks-po-guid-huzhe-int

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