Внедрение инжектора зависимости с помощью инъекции зависимости

Довольно плохо знаком с внедрением зависимости, и я пытаюсь выяснить, является ли это анти-паттерном.

Допустим, у меня есть 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 класс в этом случае, что заставляет меня думать, что это не очень хорошая практика.

Как еще я могу сделать это?

есть идеи?

Ответы на вопрос(3)

Ваш ответ на вопрос