Почему бы не раздавать Ваш контейнер МОК?
В большинстве случаев необходимо использовать IV. Так как IV сгенерирован случайным образом каждый раз при шифровании тех же данных дважды зашифрованные сообщения будут отличающимися, и для наблюдателя будет невозможно сказать, является ли это два сообщения тем же.
4 ответа
Чтобы абстрагироваться от создания экземпляра другого компонента, вы можете использовать шаблон Factory:
public interface IComponentBFactory
{
IComponentB CreateComponentB();
}
public class ComponentA : IComponentA
{
private IComponentBFactory _componentBFactory;
public ComponentA(IComponentBFactory componentBFactory)
{
_componentBFactory = componentBFactory;
}
public void Foo()
{
var componentB = _componentBFactory.CreateComponentB();
...
}
}
Затем реализация может быть зарегистрирована в контейнере IoC.
Контейнер - это один из способов сборки граф объекта, но это, конечно, не единственный способ. Это деталь реализации. Сохранение объектов свободными от этих знаний отделяет их от проблем инфраструктуры. Это также избавляет их от необходимости знать , какую версию зависимости разрешить.
IoC берет на себя ответственность за определение версии зависимости, которую должен использовать данный объект. Это полезно для таких вещей, как создание цепочек объектов, реализующих интерфейс, а также для получения зависимости от этого интерфейса (аналогично цепочке команд или шаблону декоратора).
Передавая свой контейнер, вы перекладываете ответственность на отдельный объект, чтобы получить соответствующую зависимость, поэтому он должен знать, как это сделать. При типичном использовании IoC объекту нужно только объявить, что он имеет зависимость, а не думать о выборе между несколькими доступными реализациями этой зависимости.
Шаблоны Service Locator труднее тестировать, и, конечно же, труднее контролировать зависимости, что может привести к большему количеству взаимосвязей в вашей системе, чем вы действительно хотите.
Если вы действительно хотите что-то вроде ленивого создания экземпляра, вы все равно можете выбрать стиль Service Locator (он не убивает вас сразу, и если вы придерживаетесь интерфейса контейнера, его не так уж сложно протестировать с помощью какой-то имитирующей структуры). Однако имейте в виду, что создание экземпляра класса, который мало что делает (или ничего не делает) в конструкторе, очень дешево.
Контейнер ' s Я узнал (пока что не autofac) позволит вам изменить, какие зависимости должны быть внедрены в какой экземпляр в зависимости от состояния системы, так что даже эти решения могут быть перенесены в конфигурацию контейнера.
Это может предоставить вам большую гибкость, не прибегая к реализации взаимодействия с контейнером на основе некоторого состояния, к которому вы получаете доступ в зависимостях, потребляющих экземпляр.
Autofac действительно имеет некоторые специальные функции именно для этого сценария - подробности находятся в вики здесь: http://code.google.com/p/autofac/wiki/DelegateFactories .
По сути, если A необходимо создать несколько экземпляров B, A может зависеть от Func , и Autofac сгенерирует реализацию, которая возвращает новые B из контейнера.
Другие предложения приведенные выше, конечно, действительны - подход Autofac имеет несколько отличий:
- Он позволяет избежать необходимости в большом количестве фабричных интерфейсов
- B (продукт фабрики) все еще может иметь зависимости, введенные контейнером
Надеюсь, это поможет!
Ник