Размещение Ioc-контейнера в корпоративном приложении

Question

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

В приведенных ниже статьях предлагается реализовать контейнер в «точке входа приложения»:

• Рекомендации для контейнера МОК
• МОК в проектах визуальной студии?
• Не понимаю, где создавать контейнеры IoC в архитектуре системы

Теперь - мое мысленно-экспериментальное приложение будет состоять из нескольких проектов Visual Studio (один для доступа к данным, приложение winforms). И скажем, я хочу использовать AOP для входа в систему с Log4net, и поэтому я настраиваю log4net в контейнере Ioc. Итак, приложение WinForms в точке входа - вот куда должен идти контейнер Ioc.

Вот вопрос: если я хочу регистрировать материал в моем проекте / слое доступа к данным, я должен добавить ссылка на мое приложение winforms, получить оттуда контейнер ioc, извлечь из него экземпляр log4net и использовать его для ведения журнала?

Это означало бы, что мой уровень данных зависит от приложения winforms, что не может быть правильным. Как насчет того, чтобы поместить контейнер - это что-то вроде «общего» проекта в решении. Таким образом, все связанные проекты (доступ к данным / winformsa и т. Д.) Могут получить доступ к контейнеру. Как правильно идти сюда?

Answer 1

Корень вашего приложения будет проектом Windows Forms.Это проект only , в котором должна быть ссылка на DI-контейнер.

Во всех других проектах зависимости должны вводиться через Constructor Injection .Все приличные DI-контейнеры понимают этот шаблон и используют его для Auto-wire зависимостей от корня композиции.

Answer 2

Я абстрагировал свой контейнер в отдельную сборку, которая зависит от всех других сборок / проектов в зависимости от его сервисных ссылок.Контейнерный проект имеет только один класс и - более или менее - один метод:

public class MySpecialContainer
{
     public T Resolve<T>() { // ... Get stuff from the IoC container }
}

Сборка контейнера будет происходить либо в ctor MySpecialContainer, либо просто добавит другой метод, такой как Initialize () или какой-нибудь такой.1004 *

Единственная проблема заключается в том, что этот подход сломался для меня, когда я использовал Autofac и у меня был и Windows Service, и ASP.Net проект, нуждающийся в контейнере.У каждого были свои особые требования к сервисам с ограниченным сроком службы: служба Windows - PerLifetimeScope, ASP.Net - PerHttpRequest.Я думаю, я мог бы передать аргумент в MySpecialContainer, который обозначал, какой сценарий нужно настроить, но я решил просто взять зависимость Autofac напрямую.

Хорошая новость в том, что если вы придерживаетесь инъекции ctor, тоВы можете очень легко поменять различные реализации контейнеров - Autofec, Ninject, StructureMap и т. д.