Внедрение внедрения зависимостей между несколькими решениями

У нас есть ландшафт с 15 решениями, где каждое решение содержит множество собственных проектов. Однако все решения имеют общий проект "Модель". Так как каждое решение, однако, прокладывает свои собственные графические объекты, это приводит к дублированию регистрации проекта модели 15 раз.

Какой лучший способ предотвратить это дублирование?

Пример:

Решение-A

Модель

public class Account
{
 public Account()
 {
 var a=Resolve<iemailer>();
 }
}
</iemailer>

Добавление выше кода в конструктор заставляет меня регистрировать зависимости во всех стартовых проектах решений, если они ссылаются на вышеуказанный класс. Некоторым решениям нужен класс Account но не IEmailer но при этом ему необходимо IEmailer в это решение.

1 ответ

Регистрация всего в стартовом проекте на самом деле хорошая вещь. Это обычное место называется корнем композиции, что позволяет свести к минимуму количество ссылок между вашими проектами, как это здесь четко объясняется.

Еще одна вещь, которую вы должны предотвратить, - это позволить вашему коду (за исключением вашего корня композиции) зависеть от библиотеки DI или абстракции над вашей библиотекой DI. Поэтому вместо вызова Resolve изнутри ваших конструкторов, пусть любая зависимость, которую класс вводит в конструктор этого класса. Пример:

public class Account
{
 private readonly IEmailer emailer;

 public Account(IEmailer emailer)
 {
 this.emailer = emailer;
 }
}

Это имеет много преимуществ перед возвратом в контейнер из вашего кода.

Обратите внимание, что ваш контейнер предназначен для создания графиков объектов ваших служб. Если Account является сущностью, разрешение этого вопроса из контейнера не является обычной и рекомендуемой вещью.

О проблеме с несколькими решениями, с которой вы сталкиваетесь: поскольку вы используете общий проект, может быть полезно предотвратить ссылку на него как проект, но сделать это независимым проектом со своим собственным циклом выпуска. Другие проекты могут в этом случае зависеть от сборки, которую вы публикуете (например, используя собственный локальный сервер NuGet).

Но помимо этого, поскольку это проект многократного использования, убедитесь, что сборка становится дружественной к DI библиотеке. Если необходимо выполнить загрузку, и вы хотите предотвратить повторение этого решения, создайте отдельный проект начальной загрузки. Этот проект начальной загрузки относится к библиотеке многократного использования и ссылается на ваш контейнер Unity. Таким образом, ваша библиотека по-прежнему остается полностью независимой от используемой библиотеки DI, в то время как вы предотвращаете дублирование логики начальной загрузки во всех решениях.

licensed under cc by-sa 3.0 with attribution.