接口依赖关系层次

我目前有一个主要类可能会调用另一个类，可能会调用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个依赖关系，其中大部分依赖关系在其他类中使用。有其他选择吗？

来源

2012-02-05 Jon

依赖关系应该在本地定义到它们所需的位置，即依赖关系应该在类型的构造函数上定义，然后使用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 {}

来源

2012-02-05 13:24:11

让IoC容器来做到这一点。

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

来源

2012-02-05 13:21:46 Wojteq

这听起来像你的主类是你的Composition Root。这很好 - 如果这只是只有它不会变得混乱。这应该是其唯一的责任。换句话说：您的应用程序入口点应该是Humble Object。

来源

2012-02-05 13:43:44

在这种情况下，它不是一个合成根，它是一个插件类 – Jon 2012-02-05 13:58:20

接口依赖关系层次

回答

相关问题