Как правило, я хочу, чтобы приложение полностью игнорировало контейнер IoC. Однако я столкнулся с проблемами, когда мне нужно было получить к нему доступ. Чтобы отвлечься от боли, я использую базовый Синглтон. Прежде чем бежать за холмами или вытащить дробовик, позвольте мне решить мое решение. В принципе, синглтон IoC абсолютно ничего не делает, он просто делегирует внутренний интерфейс, который должен быть передан. Я нашел, что это делает работу с Singleton менее болезненной.Тестирование контейнера IoC за синглтон - делать это неправильно?
Ниже IoC обертка:
public static class IoC
{
private static IDependencyResolver inner;
public static void InitWith(IDependencyResolver container)
{
inner = container;
}
/// <exception cref="InvalidOperationException">Container has not been initialized. Please supply an instance if IWindsorContainer.</exception>
public static T Resolve<T>()
{
if (inner == null)
throw new InvalidOperationException("Container has not been initialized. Please supply an instance if IWindsorContainer.");
return inner.Resolve<T>();
}
public static T[] ResolveAll<T>()
{
return inner.ResolveAll<T>();
}
}
IDependencyResolver:
public interface IDependencyResolver
{
T Resolve<T>();
T[] ResolveAll<T>();
}
Я имел большой успех до сих пор с несколько раз я использовал его (возможно, один раз в несколько проектов, Я действительно предпочитаю не использовать это вообще), поскольку я могу впрыскивать все, что я хочу: замок, заглушка, подделки и т. Д.
Это скользкая дорога? Могу ли я столкнуться с потенциальными проблемами в будущем?