Я использую MediatR в .Net Core и немного запутался, является ли внедрение нескольких репозиториев для обработки бизнес-логики приемлемым/чистым способом?
Мой пример кода:
public class MyRequestHandler: IRequestHandler<...>
{
public IHeaderRepository _headerRepository;
public IChildRepository _childRepository;
///constructor dependency injection happening here
public async Task<...>Handle(.....request,..... cancellationToken)
{
var header = await _headerRepository.GetHeader(..headerId);
if (header != null) await _headerRepository.Insert(...):
await _childRepository.Insert(..., ...headerId)
}
}
Похоже, вы вставляете только один агрегат. Таким образом, вы не нарушаете «совокупный» контракт. Так что, пока это условие выполняется, да, он имеет право читать из других репозиториев.
Однако, я думаю, путь - это события. Итак, когда заголовок создан, событие должно быть опубликовано, а затем
MyRequestHandler
следует вставлять данные с помощью childRepository
.
спасибо за ответ, но когда вы говорите, что «событие должно быть опубликовано», вы имеете в виду, что я должен создать отдельный обработчик и вызвать его в своем классе «MyRequestHandler» через mediatr.Send/mediatr.Publish?
@zxc Я нашел действительно классный пост. Я думаю, это то, что вы можете сделать использовать несколько репозиториев из одного обработчика команд. Так что стоит прочитать другие ответы. Если вы действительно хотите удалить второй репозиторий, вы можете вызвать службу домена, как в ссылке.
На самом деле это не вопрос MediatR. И является ли это приемлемым или чистым, субъективно. У вас есть класс, которому нужно взаимодействовать с двумя зависимостями (репозиториями), чтобы что-то выполнить. В этом нет ничего необычного. Интересно, действительно ли ваш вопрос касается чего-то другого, например отношения между данными в репозиториях. Но взаимодействие класса с двумя зависимостями вовсе не является чем-то необычным. Я был бы обеспокоен, если бы у него было 5, 10 или 20 зависимостей.