了解 Ninject 的好处

Question

我已经看到这个问题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 文档“手动依赖注入”-No 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 为我提供了哪些仅遵循松散耦合的基本原则我无法做到的事情？感谢您帮助我理解。

Answer 1

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 个位置都不会改变**。因此它可以帮助您避免在需要新依赖项时修改现有代码。

** 情况并非总是如此，但这是一个简化的示例，展示了没有人谈论太多的额外好处之一。

Answer 2

使用 Ninject 为我提供了我无法做到的事情 遵循松散耦合的基本原则？

• Composition Root 中的代码行更少
• 用于处理对象生命周期的标准容器
• 许多插件用于特定上下文中的注入，例如经典 WebForms、ASP.NET MVC、ASP.NET Web API
• 可以自动处理您的 IDIsposable 对象
• ...

否则，您应该手动处理的所有事情。话虽如此，DI框架并不重要。它应该很快，并提供您的应用程序所需的特定功能。但是 DI 框架绝对不应该以松散耦合的方式影响您设计代码和应用程​​序中不同层的方式（针对接口和抽象类进行编程以削弱应用程序不同层之间的耦合）。

因此，可以将 DI 框架视为仅干预应用程序的组合根的东西，并且可以将其视为一个框架，您可以在眨眼之间将其替换为不同的框架，甚至可以手动处理您的对象生命周期。

例如，您在问题中显示的代码非常糟糕，因为它将您的层与特定的 DI 框架联系在一起。那边的[Inject] 属性就像癌症一样。这意味着您的应用程序代码依赖于特定的 DI 框架。

Answer 3

如果你想测试你的程序怎么办？使用您的手动方法，测试环境现在取决于定义的 Shuriken() 和 Sword()。

使用像 Ninject 这样的框架，您可以创建应用程序，以便在实际运行应用程序时引入依赖项。这意味着您可以传入模拟数据，因此现在您的测试环境将没有依赖关系。