Я могу передать параметры конструктора Твердости Единицы () метод?

Я думаю, что altCognito ' Ответ s (FlushFileBuffers), вероятно, лучший, но только потому, что TFileStream не выполняет буферизацию самостоятельно. Для других буферизованных потоков сначала нужно посмотреть, предлагает ли поток метод Flush. И в крайнем случае вы могли бы использовать старый трюк Seek (Begin), а затем Seek (CurrentPos).

но вместо этого использовать файл XML для создания фиктивных данных для теста? Как бы вы пошли о подаче содержимого XML в этот конструктор?

IoC основан на разъединении кода, связывая тип и семантику аргументов с конкретными типами, вы действительно не делали разделение правильно, все еще есть зависимость.

«Этот код может взаимодействовать с любым типом репозитория, возможно, при условии, что он реализует этот интерфейс ... О, и использует контекст данных».

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

NotDan, я думаю, что вы, возможно, ответили на свой вопрос в комментариях к lassevk.

Во-первых, я бы использовал LifetimeManager для управления жизненным циклом и количеством экземпляров IDataContext, которые создает Unity.
http://msdn.microsoft.com/en-us/library/cc440953.aspx

Похоже, что объект ContainerControlledLifetimeManager предоставит вам необходимое управление экземплярами. С этим LifetimeManager Unity должна добавить один и тот же экземпляр IDataContext ко всем объектам, для которых требуется зависимость IDataContext.

Очень короткий ответ: нет. Unity в настоящее время не имеет возможности передавать параметры в конструктор, которые не являются постоянными или введенными, что я смог найти. ИМХО, это единственное, чего не хватает, но я думаю, что это дизайн, а не упущение.

Как отмечает Джефф Фриц, теоретически вы можете создать собственный менеджер времени жизни, который знает, какой экземпляр контекста внедрить в различные типы, но это уровень жесткого кодирования, который, кажется, устраняет цель использования Unity или DI в первом место.

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

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

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

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

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

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

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

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

IDataContext context = _unityContainer.Resolve<IDataContext>();
_unityContainer.RegisterInstance(context);
var repositoryA = _unityContainer.Resolve<IRepositoryA>(); //Same instance of context
var repositoryB = _unityContainer.Resolve<IRepositoryB>(); //Same instance of context


//declare _unityContainer2
IDataContext context2 = _unityContainer2.Resolve<IDataContext>(); //New instance
_unityContainer2.RegisterInstance(context2);
var repositoryA2 = _unityContainer2.Resolve<IRepositoryA>(context2); //will retrieve the other instance

надеюсь, это тоже поможет

Вы можете использовать InjectionConstructor / InjectionProperty / InjectionMethod в зависимости от вашей архитектуры внедрения в ResolvedParameter («имя»), чтобы получить экземпляр предварительно зарегистрированного объекта в контейнере.

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

_unityContainer.RegisterType<IDataContext,DataContextA>("DataContextA", new ContainerControlledLifeTimeManager());
_unityContainer.RegisterType<IDataContext,DataContextB>("DataContextB");

  var repositoryA = _unityContainer.Resolve<IRepositoryA>(new InjectionConstructor(
new ResolvedParameter<IDataContext>("DataContextA")));

  var repositoryB = _unityContainer.Resolve<IRepositoryB>(new InjectionConstructor(
new ResolvedParameter<IDataContext>("DataContextA")));

  var repositoryA2 = _unityContainer.Resolve<IRepositoryA>(new InjectionConstructor(
new ResolvedParameter<IDataContext>("DataContextB")));