Question

我目前有一个主类可能会调用另一个可能会调用2或3个其他类的类。主类也可以创建一个Windows表单。

所以目前我们可能会：

public class MainClass
{
  ...
  AnotherClass = new AnotherClass();
  fmMain myForm = new fmMain();
}

public class AnotherClass
{
  ...
  DatabaseClass dbClass = new DatabaseClass();
  FileClass fClass = new FileClass();
}

正如我所看到的，在重构和放入构造函数接口依赖项之后，我可以使用IOC容器。

问题是我的入口点是主类，所以我只能看到主要类构造函数中的所有依赖项，然后将它们传递给其他类和表单。

问题是这可能会非常混乱，主类可能有10个依赖项，其中大多数都在其他类中使用。还有其他选择吗？

Answer 1

让IoC容器执行此操作。

将AnotherClass注册为依赖项，然后直接引用容器实例解析它。

Answer 2

依赖关系应该在本地定义到它们所需的位置，即依赖关系应该在类型的构造函数上定义，然后使用IoC容器来解析所有类型。通过这种方式，IoC负责“将这些传递到其他类和表单中”。使用IoC容器时尽量避免使用“new”，而是使用容器创建实例。它将为您处理依赖项的创建和注入。

例如（使用Ninject），下面演示了Form，它定义了自己的依赖项。当用于解析ProductForm的实例时，容器将提供并注入所有依赖递归。

不需要将依赖项注入入口点类，但是在模块中将其指定为绑定，然后在解析Forms等类型时由容器注入。

public class Program
{
    public Program()
    {
        IKernel kernel = new StandardKernel(new MainModule());

        Form form = kernel.Get<ProductForm>();

        form.Show();
    }
}

public class MainModule : NinjectModule
{
    public override void Load()
    {
        Bind<ProductForm>().ToSelf();
        Bind<IProductService>().To<ProductService>();
        Bind<IProductDb>().To<IProductDb>();
    }
}

internal class ProductForm : Form
{
    private readonly IProductService _productService;

    public ProductForm(IProductService productService)
    {
        _productService = productService;
    }
}

internal interface IProductService {}

internal class ProductService : IProductService
{
    private readonly IProductDb _productDb;

    public ProductService(IProductDb productDb)
    {
        _productDb = productDb;
    }
}

internal interface IProductDb {}

internal class ProductDb : IProductDb {}

Answer 3

听起来您的主要课程是Composition Root。那很好 - 如果它只是那么它就不会变得混乱。这应该是它的唯一责任。换句话说：您的应用程序入口点应为Humble Object。

接口依赖层次结构

3 个答案: