.net - 我是否正确理解DI/IoC？

Question

Closed. This question needs to be more focused。它当前不接受答案。












想要改善这个问题吗？更新问题，使它仅关注 editing this post的一个问题。

4年前关闭。



Improve this question




我目前正在尝试学习使用IoC容器的好处，并熟悉DI。我已经开始使用StructureMap，因为它看起来非常简单但功能强大。

我想证明我对这些概念的理解是正确的。让我们假设应用程序中的以下基本类(为简洁起见，省略了详细信息):

public class OrderService : IOrderService
{
    private IOrderRepository _repository;
    private ITaxCalculator _taxCalculator;
    private IShippingCalculator _shippingCalculator;

    public OrderService(IOrderRepository repository, 
        ITaxCalculator taxCalculator, 
        IShippingCalculator shippingCalculator)
    {
        this._repository = repository;
        this._shippingCalculator = shippingCalculator;
        this._taxCalculator = taxCalculator;
    }

    public IOrder Find(int id) { return this._repository.Find(id); }
}

public class OrderRepository : IOrderRepository
{
    public IOrder Find(int id) { // ... }
}

public class StandardShippingCalculator : IShippingCalculator
{
    // ...
}

public class StandardTaxCalculator : ITaxCalculator
{
    private ITaxSpecification _specification;

    public StandardTaxCalculator(ITaxSpecification specification)
    {
        this._specification = specification;
    }
}

首先，依赖性反转原则指出，由于OrderService是“高级”模块，因此它不依赖于任何较低级别的实现细节，它应该仅引用这些类并能够要求它们不必知道自己在做什么就可以完成自己的事情，而使用这些代码的人应该负责创建和处理这些预配置的模块。是对的吗？因此，DI使这些类保持松散耦合，以便它们不必知道调用该依赖项的方法的确切方式，只需简单地将 调用并执行所需的任何操作即可-OrderService不会注意存储库是在查询XML，还是使用NHibernate或EF甚至是原始数据集；它只知道可以调用存储库，告诉它找到ID为42的订单，存储库就知道该怎么做。

我的理解是，在这种情况下，IoC容器StructureMap提供了一个好处，即无需强制我们确保手动创建所有这些依赖项并将它们传递给我们。例如，使用上面的代码可能具有:

static void Main(string[] args)
{
    IOrderService service = new OrderService(
        new OrderRepository(), new StandardShippingService(), 
        new StandardTaxService(new StandardTaxSpecification()));

    IOrder order = service.Find(42);

    // Do something with order...
}

所有的新闻都令人讨厌地设置它；即使我创建了变量，它仍然很难看。使用IoC容器可以避免所有这些情况，在StructureMap的情况下，它将变为:

static void Main(string[] args)
{
    ObjectFactory.Initialize(x =>
    {
        x.For<IOrderRepository>().Use<OrderRepository>();
        x.For<IOrderService>().Use<OrderService>();
        x.For<IOrder>().Use<Order>();
        x.For<IShippingCalculator>()
                        .Use<StandardShippingCalculator>();
        x.For<ITaxCalculator>().Use<StandardTaxCalculator>();
        x.For<ITaxSpecification>()
                        .Use<StandardTaxSpecification>();
    });

    IOrderService service =
                ObjectFactory.GetInstance<IOrderService>();
    IOrder order = service.Find(42);
    // do stuff with order...
}

这是更干净，更易于维护的方法，并且如果我正在编写单元测试，则可以让我仅将其具体类分割为一个Mock。简而言之，好处是它可以将所有内容进一步解耦到我什至不必关心的地方(在调用代码中)，即某个特定类所依赖的地方，我可以使用容器创建一个，然后让它去做就是这样，并确保使用方的代码仅知道其需要的内容-例如，在实际应用中，如果Controller正在调用服务，则无需了解存储库，计算器或规范，它所需要知道的就是使用OrderService对Order做某事。

这理解正确吗？关于这一点，有些事情我还不确定:

如果您决定使用IoC容器，是要在应用程序中的任何地方使用它，还是仅在您有许多要解决的倒置依赖项的地方使用？例如，在OrderRepository中，如果我使用的是具体实现并更新Order；此类也将使用StructureMap来获取订单吗？这可能是一个愚蠢的问题，但我见过的所有DI/IoC示例仅专注于在使用客户端(例如网页)中使用它，而从不涉及在其他地方使用它。似乎这是一种全有或全无的方法:如果您要使用IoC容器，那么它随处可见。您实际上是将对new SomeObject();的所有调用替换为ObjectFactory.GetInstance<ISomeObject>();

是否需要从接口(interface)派生每个类(当然，可能的话)是否需要使用DI/IoC或模拟它，这是好是坏？我看过很多代码示例，其中每个非内置类都在其后方提供接口(interface)，虽然我可以看到这样做的好处和可能的面向 future ，但我认为遵循TDD或BDD可能会这里的因素是，使用这些方法通常会告诉您是否需要一个类的接口(interface)，但是我见过很多人，无论他们是否TDD都认为您永远不应将对象的类型定义为具体的类；它应该始终作为底层类型的接口(interface)或抽象类。这似乎是“不必要的复杂性”代码气味的一种情况，更不用说违反了YAGNI了。

最佳答案

您的两个问题都涉及有争议的话题，但是我会在辩论中坚持自己的观点。

If you decide to use an IoC container, is it meant to be used everywhere in the application, only where you have many inverted dependencies to resolve, or only in the consumer?

顶级应用程序(使用者)是唯一应该了解依赖项注入(inject)框架的组件。您无需在整个代码库中替换 new，因为每个对象都应具有完成其工作所需的所有依赖关系实例(MiškoHevery的“ Dependency Injection Myth: Reference Passing”最终为我带来了这个家)。

Is it considered good or bad to have every class (where possible, of course) derive from an interface whether or not there's a need to use DI/IoC or something like mocking it?

该问题的其余部分表明，您已经知道答案:仅构建接口(interface)以创建更合适的抽象(比所讨论的具体类)或提供其他一些值(value)。

关于.net - 我是否正确理解DI/IoC？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4608221/

上一篇：entity-framework - 是否可以改善 EF6 预热时间？

下一篇：entity-framework - ASP.net 身份、IoC 和共享 DbContext

相关文章：

c# - 如何检查 var 的空值？

c# - `HashSet<T>.IsSubsetOf()` 和 `HashSet<T>.IsProperSubsetOf()` 有什么区别

c# - 使用 Simple Injector 将依赖项注入(inject) OWIN 中间件和每个 Web 请求

c# - 无法解决 IServerSideEvents 依赖

inversion-of-control - 自定义配置注入(inject) - CaSTLe Windsor/IoC 的新手

asp.net-mvc - Unity.MVC4惰性<T>在ASP.NET MVC应用程序中不起作用

c# - 从从未 Hook 的事件中解开委托(delegate)是否有任何问题？

c# - WPF DataGrid HeaderTemplate 神秘填充

typescript - 在 Inversify 中，为什么更喜欢 Constructor/Factory 注入(inject)而不是 toDynamicValue？

php - 在 Laravel 5 中实例化依赖关系，好方法

Answer 1

您的两个问题都涉及有争议的话题，但是我会在辩论中坚持自己的观点。

If you decide to use an IoC container, is it meant to be used everywhere in the application, only where you have many inverted dependencies to resolve, or only in the consumer?

顶级应用程序(使用者)是唯一应该了解依赖项注入(inject)框架的组件。您无需在整个代码库中替换 new，因为每个对象都应具有完成其工作所需的所有依赖关系实例(MiškoHevery的“ Dependency Injection Myth: Reference Passing”最终为我带来了这个家)。

Is it considered good or bad to have every class (where possible, of course) derive from an interface whether or not there's a need to use DI/IoC or something like mocking it?

该问题的其余部分表明，您已经知道答案:仅构建接口(interface)以创建更合适的抽象(比所讨论的具体类)或提供其他一些值(value)。