11

我已经阅读了数十篇关于这个主题的帖子，但没有找到关于如何在不使用服务定位器模式的情况下访问 Ninject.Kernel 的明确指南。

我目前在需要使用的类中有以下内容CustomerBusiness（这是我的服务）并且工作正常，但我很清楚这不是推荐的方法。

private CustomerBusiness _customerBusiness;

private ICustomerRepository CustomerRepository
{
    get { return NinjectWebCommon.Kernel.Get<IAccountRepository>(); }
}

private CustomerBusiness CustomerBusiness
{
    get
    {
        if (_customerBusiness == null)
        {
            _customerBusiness = new CustomerBusiness(AccountRepository);
        }

        return _customerBusiness;
    }
}

public Customer GetCustomer(int id)
{
    return CustomerBusiness.GetCustomer(id);
}

这是上面代码中访问的 Kernel 属性：

public static IKernel Kernel
{
    get
    {
        return CreateKernel();
    }
}

我已经阅读了很多关于为此使用工厂的建议，但没有一个解释如何使用这个工厂。如果有人能向我展示“CustomerFactory”或任何其他推荐的方法，包括如何使用它，我将不胜感激。

更新

我正在使用 ASP.NET Web 窗体，需要CustomerBusiness从 CodeBehind 访问。

解决方案

我发现有效的最终解决方案是在这篇文章中获得最多票数的答案： 如何在 asp.net Web 表单上实现 Ninject 或 DI？

它看起来像这样（注意从 PageBase 继承，它是 Ninject.Web 的一部分 - 这是关键！）：

public partial class Edit : PageBase
{
    [Inject]
    public ICustomerBusiness CustomerBusiness { get; set; }
    ...

下面接受的答案间接引导我找到这个解决方案。

4

2 回答 2

12

由于您使用的是NinjectWebCommon，我假设您有某种 Web 应用程序。你真的应该只在一个地方访问 Ninject 内核——在组合根目录。它是您构建对象图的地方，也是您唯一需要访问 IoC 容器的地方。要真正获得所需的依赖项，通常会使用构造函数注入。

例如，对于 MVC Web 应用程序，您有一个使用 Ninject 内核的控制器工厂，这是唯一引用它的地方。

为了扩展您的特定情况，您的类将ICustomerBusiness在其构造函数中接受，声明它需要一个实例ICustomerBusiness作为其依赖项：

class CustomerBusinessConsumer : ICustomerBusinessConsumer
{
    private readonly ICustomerBusiness customerBusiness;

    public CustomerBusinessConsumer(ICustomerBusiness customerBusiness)
    {
        this.customerBusiness = customerBusiness;
    }
    ...
}

现在，无论哪个类ICustomerBusinessConsumer用作其依赖项，都将遵循相同的模式（接受一个实例ICustomerBusinessConsumer作为其构造函数参数）。您基本上从不使用手动构建依赖项new（除了特定例外）。

然后，您只需要确保您的类获得它们的依赖项，并且您在此组合根中执行此操作。组合根到底是什么取决于您正在编写的应用程序的类型（控制台应用程序、WPF 应用程序、Web 服务、MVC Web 应用程序......）

编辑：为了让自己熟悉 ASP.NET WebForms 领域的情况，我必须查看详细信息，因为我从未使用过它。不幸的是，WebForms 要求您在每个 Page 类中都有一个无参数的构造函数，因此您不能从对象图的顶部到底部一直使用构造函数注入。

然而，在查阅Mark Seeman关于在 WebForms 中组合对象的章节之后，我可以重新表述如何处理这个框架的低效率，同时仍然符合良好的 DI 实践：

  1. 有一个类负责解决依赖关系，使用您设置的 Ninject 内核。这可能是内核周围的一个非常薄的包装器。让我们称之为DependencyContainer。

  2. 创建您的容器并将其保存在应用程序上下文中，以便在您需要时准备好它

    protected void Application_Start(object sender, EventArgs e)
{
   this.Application["container"] = new DependencyContainer();
}

  3. 假设您的页面类（我们称之为HomePage）依赖于ICustomerBusinessConsumer. 然后DependencyContainer必须允许我们检索以下实例ICustomerBusinessConsumer：

    public ICustomerBusinessConsumer ResolveCustomerBusinessConsumer()
{
    return Kernel.Get<ICustomerBusinessConsumer>();
}

  4. 与MainPage类本身相比，您将在默认构造函数中解析其依赖项：

    public MainPage()
{
    var container = (DependencyContainer) HttpContext.Current.Application["container"];
    this.customerBusinessConsumer = container.ResolveCustomerBusinessConsumer();
}

几点注意事项：

  • 在 中拥有可用的依赖容器HttpContext一定不要将其视为服务定位器。事实上，这里的最佳实践（至少从忠实于 DI 的角度来看）是拥有某种“实现器”类，您将向其传递页面类的功能。

    例如，由其处理的每个动作MainPage将仅中继到其实现者类。这个实现类将是一个依赖项，MainPage并且与所有其他依赖项一样，将使用容器解析。

    重要的部分是这些实现类应该在不引用 ASP.NET 程序集的程序集中，因此没有机会访问HttpContext

  • 必须编写这么多代码来实现这一点当然不理想，但这只是框架限制的结果。例如，在 ASP.NET MVC 应用程序中，这种情况的处理方式要好得多。在那里，您可以单点组成对象图，而不必像在 WebForms 中那样在每个顶级类中解析它们。

  • 好消息是，虽然您必须在页面类构造函数中编写一些管道代码，但从那里向下对象图您可以使用构造函数注入

于 2012-08-12T10:24:14.670 回答
1

构造函数注入是带有 ninject 的 DI 的首选方法，但它也支持属性注入。在此处阅读有关注入模式的 ninject 页面https://github.com/ninject/ninject/wiki/Injection-Patterns。

这两种都是注入模式，与基于请求的服务位置不同，根本不是真正的注入。

注入的另一面是你需要控制构造。使用 MVC 时，执行此操作的所有接线都内置在 nuget 上的 MVC ninject 包中

于 2012-08-12T10:24:28.950 回答