Внедрение инжектора зависимости с помощью инъекции зависимости
Довольно плохо знаком с внедрением зависимости, и я пытаюсь выяснить, является ли это анти-паттерном.
Допустим, у меня есть 3 сборки:
Foo.Shared - this has all the interfaces
Foo.Users - references Foo.Shared
Foo.Payment - references Foo.Shared
Foo.Users нужен объект, который встроен в Foo.Payment, а Foo.Payment также нужны вещи из Foo.Users. Это создает некую круговую зависимость.
Я определил интерфейс в Foo.Shared, который использует прокси-платформу Dependency Injection, которую я использую (в данном случае NInject).
public interface IDependencyResolver
{
T Get<T>();
}
В приложении контейнера у меня есть реализация этого интерфейса:
public class DependencyResolver:IDependencyResolver
{
private readonly IKernel _kernel;
public DependencyResolver(IKernel kernel)
{
_kernel = kernel;
}
public T Get<T>()
{
return _kernel.Get<T>();
}
}
Конфигурация выглядит так:
public class MyModule:StandardModule
{
public override void Load()
{
Bind<IDependencyResolver>().To<DependencyResolver>().WithArgument("kernel", Kernel);
Bind<Foo.Shared.ISomeType>().To<Foo.Payment.SomeType>(); // <- binding to different assembly
...
}
}
Это позволяет мне создавать новый объектFoo.Payment.SomeType
изнутри Foo.Users без прямой ссылки:
public class UserAccounts:IUserAccounts
{
private ISomeType _someType;
public UserAccounts(IDependencyResolver dependencyResolver)
{
_someType = dependencyResolver.Get<ISomeType>(); // <- this essentially creates a new instance of Foo.Payment.SomeType
}
}
Это делает неясным, каковы точные зависимостиUserAccounts
класс в этом случае, что заставляет меня думать, что это не очень хорошая практика.
Как еще я могу сделать это?
есть идеи?