Зависимость впрыска через Inteface и структуру проекта

Question

Этот вопрос немного сложно объяснить, но я постараюсь изо всех сил.

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

Теперь моя структура проекта находится под одним решением в визуальной студии:

проекта A: UI

Проект B: API для получения данных от службы третьей стороны

Project C: Нить Управляющий API

Примечание: Проект B имеет интерфейс IB, а C имеет интерфейс IC, который помогает впрыскивать зависимость. Проекты B и C будут использоваться другими командами в будущем.

Проект A использует интерфейсы IB ​​и IC для инъекции зависимостей.

Теперь я изложу свое понимание IOC: DIP говорит, что модуль высокого уровня не должен зависеть от низкоуровневого модуля, и как высокоуровневый, так и низкоуровневый модуль должен зависеть от абстракции. Если вы хотите предотвратить изменения в модуле высокого уровня при смене модуля низкого уровня, вам необходимо инвертировать элемент управления, чтобы низкоуровневый модуль не контролировал интерфейс и не создавал объекты, которым нужен модуль высокого уровня.

В соответствии с вышеприведенным определением в проекте A должны быть определены как интерфейсы IB, так и IC. Если они находятся в проекте A, то как другие команды будут использовать интерфейсы IB ​​и IC? Я делаю еще один отдельный проект для хранения интерфейсов?

Answer 1

Рассмотрим следующий пример организации проекта для вашего сценария:

Проект А: Загрузчик, отвечающий за запуск приложения, настройки DI и настройка пользовательского интерфейса (это может также пойти в специальном загрузчике проекте развязкой из приложения и пользовательского интерфейса). Значения B, C, D, E, F

Проект B: пользовательский интерфейс (или столько проектов, сколько требуется для его модульной работы). (gets data from a third party service and does deserialization and some thread management work). Knows D

Проект D: интерфейсы, содержащие IB и IC (у них также могут быть отдельные выделенные проекты).

Project E: The API to get data from third party serviceЗнает D

Проект F: The Thread Manager APIЗнает D

Обратите внимание на развязывающий из пользовательского интерфейса и реализации через слой бизнес-логики. Таким образом, вы можете переключать детали реализации, не изменяя ни бизнес-логику, ни пользовательский интерфейс. Кроме того, если ваша бизнес-логика меняется, воздействие минимизируется.

Относительно DI, проект начальной загрузки является единственным, у которого есть весь рисунок, остальные должны просто использовать интерфейсы, которые контейнер, настроенный загрузчиком, будет разрешать (то есть впрыскивать) для них.

Answer 2

В соответствии с приведенным выше определением должны быть определены как интерфейсы IB, так и IC в проекте A справа?

Нет. Вы должны заменить термин «модуль» на «класс». В этом случае он начинает больше смысла:

высокого уровня [класс] не должен зависеть от низкого уровня [класс], и оба высокого уровня и низкий уровень [классы] должен зависеть от абстракции ,

Для правильной инъекции зависимостей не имеет значения, в каких узлах расположены эти классы и абстракции. Когда проект становится больше (т. Е. Несколько миллионов строк кода, одна или несколько команд, работающих на нем), становится важным придерживаться Principles of Component Design.

В вашем случае, поскольку оба узла A и B используют интерфейс IB, а сборка A зависит от сборки B, IB никогда не может быть размещена в сборе A, поскольку в этом случае будет кольцевая ссылка в сборке. Вам нужно либо поставить IB в сборку B, либо в новую сборку, на которую ссылаются как A, так и B.