CodeGo.net>了解Ninject的好处

我已经看到了Still need help understanding why Ninject might be better than manual DI这个问题,但我仍然对Ninject的实用性感到困惑…

我了解这段代码…

class Samurai
{
    readonly IWeapon weapon;

    [Inject]
    public Samurai(IWeapon weapon)
    {
        this.weapon = weapon;
    }

    public void Attack(string target) 
    {
        this.weapon.Hit(target);
    }
}

…将产生以下“(基本上)如下所示的动态方法：”

delegate(IWeapon weapon)
{
    return new Samurai(weapon);
}

这到底有什么用？没有Ninject,我仍然可以执行此操作(根据Ninject文档“手动进行依赖项注入”-没有Ninject)：

class Program
{
    public static void Main() 
    {
        var warrior1 = new Samurai(new Shuriken());
        var warrior2 = new Samurai(new Sword());
        warrior1.Attack("the evildoers");
        warrior2.Attack("the evildoers");
    }
}

仅遵循松散耦合的基本原理,使用Ninject可以为我提供什么？感谢您帮助我理解.

解决方法:

Darin的答案涵盖了使用DI框架的最重要的好处,但是当我使用DI容器时,这里有一些帮助.假设您有一个具有以下服务依赖性的对象：

public class Order : IOrder
{
    public Order(IOrderService orderSvc, ICustomerService custSvc)
    {
        // constructor logic
    }
}

您的代码可能看起来像这样：

var order = new Order(new OrderService(), new CustomerService()); // manual
or
var order = kernel.Resolve<IOrder>(); // using a DI container

这工作正常并且很好.现在,您的要求突然改变了.现在订购需要送货服务：

public Order(IOrderService orderSvc, 
    ICustomerService custSvc, IShippingService svc)
{
    // constructor logic
}

假设您在整个程序中有10个不同的位置,这些位置是您手动创建订单的.如果您自己处理注射,则必须在代码中找到要创建订单的所有10个位置并进行修改.这样做10次可能是很多工作！

var order = new Order(new OrderService(), new CustomerService(), new ShippingService());

但是,使用DI容器后,一旦注册绑定,所有这10个地方的代码将如下所示：

var order = kernel.Resolve<IOrder>();

看看和以前一样吗？您无需更改任何内容！无论是添加1个依赖关系还是添加100个依赖关系,解决订单的所有那10个地方都不会改变**.因此,当需要新的依赖关系时,它可以帮助您避免修改现有代码.

**并非总是如此,但这是一个简化的示例,显示了没人谈论太多的其他好处之一.

标签：dependency-injection,ninject,c,inversion-of-control
来源： https://codeday.me/bug/20191122/2062381.html