Лучшие практики для контейнера IOC

можно зарегистрировать контейнер сам по себе и вводить его как любое свойство зависимости, как так:

IUnityContainer container = new UnityContainer();
container.RegisterInstance<IUnityContainer>(container);

классы, которые должны получить доступ к нему, будут иметь следующее свойство:

private IUnityContainer unityContainer;
[Dependency]
public IUnityContainer UnityContainer
{
    get { return unityContainer; }
    set { unityContainer = value; }
}

таким образом, контейнер введен каждый раз, когда экземпляр такого класса решен/создан.

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

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

Другим вариантом будет использование CommonServiceLocator , хотя это может быть бессмысленным косвенным указанием, вы можете использовать ServiceLocator.Current в качестве экземпляра, известного всем классам

У меня есть сообщение на эту тему в моем блоге, где я использую что-то вроде ответа t3mujin. Не стесняйтесь использовать его (не беспокойтесь, что это связано с sharepoint ... это не имеет значения):

http://johanleino.spaces.live.com/blog/cns!6BE273C70C45B5D1!213.entry

ИМХО, не рекомендуется вводить весь контейнер в класс или иметь статическую службу IoC для всего приложения локатор.

Вы хотите видеть из конструктора класса (назовем его Foo), какие службы / объекты он использует для выполнения работы. Это улучшает ясность, тестируемость и дегазируемость.

Допустим, Foo нужна только служба электронной почты, но я передаю весь контейнер и где-то в коде служба электронной почты получает разрешение из контейнера. В этом случае уследить будет очень сложно. Вместо этого лучше внедрить почтовую службу напрямую, чтобы более четко указать зависимости Foo.

Если Foo нужно создать несколько экземпляров почтовой службы, лучше создать и внедрить EmailServiceFactory (через контейнер IoC), который будет создавать необходимые экземпляры на лету.

В последнем случае зависимости Foo по-прежнему указываются как можно более конкретными - только те, которые может создать EmailServiceFactory. Если бы я внедрил весь контейнер, было бы непонятно, какие услуги, предоставляемые им, являются точными зависимостями Foo.

Теперь, если я позже захочу предоставить другие экземпляры почтовой службы, я заменю их внутри EmailServiceFactory. Я мог бы поменять местами и всю фабрику, если все сервисы, которые она создает, нужно поменять местами (например, во время тестирования).

Таким образом, ценой создания одного дополнительного класса (фабрики) я получил гораздо более чистый код и выиграл Не нужно беспокоиться о любопытных ошибках, которые могут возникнуть при использовании глобальной статики. Кроме того, при поставке моков для тестирования я точно знаю, что им нужно, и не делаю этого. • Имитировать типы всего контейнера.

Этот подход также имеет то преимущество, что теперь, когда модуль инициализирован (применяется только к Prism / Modularity), ему не нужно регистрировать все типы объектов он поставляется с контейнером IoC. Вместо этого он может просто зарегистрировать свой ServiceFactory, который затем предоставляет эти объекты.

Для ясности, класс инициализации модуля (реализует IModule) должен по-прежнему получать контейнер IoC для всего приложения в своем конструкторе, чтобы предоставлять услуги, которые потребляются другими модулей, но контейнер не должен вторгаться в классы модуля.

Наконец, мы имеем еще один прекрасный пример того, как дополнительный уровень косвенного обращения решает проблему.

когда модуль инициализируется (применяется только к Prism / Modularity), ему не нужно регистрировать все типы объектов, которые он поставляет с контейнером IoC. Вместо этого он может просто зарегистрировать свой ServiceFactory, который затем предоставляет эти объекты.

Для ясности, класс инициализации модуля (реализует IModule) должен по-прежнему получать контейнер IoC для всего приложения в своем конструкторе, чтобы предоставлять услуги, которые потребляются другими модулей, но контейнер не должен вторгаться в классы модуля.

Наконец, мы имеем еще один прекрасный пример того, как дополнительный уровень косвенного обращения решает проблему.

когда модуль инициализируется (применяется только к Prism / Modularity), ему не нужно регистрировать все типы объектов, которые он поставляет с контейнером IoC. Вместо этого он может просто зарегистрировать свой ServiceFactory, который затем предоставляет эти объекты.

Для ясности, класс инициализации модуля (реализует IModule) должен по-прежнему получать контейнер IoC для всего приложения в своем конструкторе, чтобы предоставлять услуги, которые потребляются другими модулей, но контейнер не должен вторгаться в классы модуля.

Наконец, мы имеем еще один прекрасный пример того, как дополнительный уровень косвенного обращения решает проблему.