Ogólnie rzecz biorąc, chciałbym, aby aplikacja zupełnie nie znała kontenera IoC. Jednak natknąłem się na problemy, w których potrzebowałem uzyskać do niego dostęp. Aby usunąć ból, używam podstawowego Singletona. Zanim wybierzesz się na wzgórza lub wyciągniesz strzelbę, pozwól mi przejrzeć moje rozwiązanie. Zasadniczo singleton IoC absolutnie nic nie robi, po prostu przenosi się do wewnętrznego interfejsu, który musi zostać przekazany. Odkryłem, że to sprawia, że praca z Singletonem jest mniej bolesna.Abstrahowanie do kontenera IoC za Singleton - Czy to źle?
Poniżej jest owinięcie 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>();
}
miałem wielki sukces do tej pory kilka razy używałem go (może raz na kilka projektów, Naprawdę wolę nie używać tego w ogóle), ponieważ mogę wstrzyknąć wszystko, czego chcę: zamek, kikut, podróbki itp.
Czy to śliska droga? Czy napotkam potencjalne problemy w dół drogi?