Я понимаю, что с помощью S # arp Architecture логика предметной области (также известная как бизнес-логика) работает с более чем одним типом сущности лучше всего обрабатывается на уровне служб приложений.
Таким образом, классам в Application Services потребуется доступ к репозиториям. Предположительно, тогда вы вводите репозитории через конструкторы. Поскольку для каждого типа сущности существует один класс репозитория, для любой достаточно реалистичной задачи потребуется доступ к нескольким репозиториям. Итак, у вас может быть класс Application Services, выглядящий следующим образом:
public class DogTasks
{
public DogTasks(IRepository<Dog> dogRepository,
IRepository<Trick> trickRepository,
IRepository<DogTrick> dogTrickRepository,
IRepository<Lesson> lessonRepository)
{
// etc
}
public void TeachDogNewTrickAtALesson(int dogID, string trickName, int lessonID)
{
// etc
}
// other methods, etc
}
Затем этот Tasks класс можно ввести в соответствующий контроллер.
Пока, думаю, я понял. Но меня беспокоит следующее:
Когда мне нужен новый метод Application Services, который использует комбинацию репозиториев, которых у меня еще нет, я должен выбрать между изменением конструктора для одного из моих существующих классов, чтобы он принял новые репозитории, или запуском нового класса в целом. Добавление аргументов в конструкторы нарушает многие модульные тесты, но распространение новых классов тоже нехорошо.
Когда контроллерам необходимо выполнять простые операции с репозиториями (например,
get), имеет смысл внедрить репозитории в контроллеры, а также в классы служб приложений. Но затем я получаю ту же проблему с «изменением аргументов конструктора». Другая альтернатива, кажется, состоит в том, чтобы позволить уровню Application Services играть с репозиториями, но тогда вы получите много шаблонного кода, добавленного в Application Services, чтобы делать очень простые вещи.
Подобные вещи заставляют меня думать, что я делаю это неправильно. Итак, как следует организовать хороший уровень Application Services?
например У вас есть много классов, каждый из которых выполняет по одной задаче? Или вы объединяете связанные задачи вместе по линиям сущностей? Как вы справляетесь с задачами, требующими большого количества репозиториев? Означает ли необходимость в большом количестве репозиториев для выполнения задачи, что пора вернуться к чертежной доске?
