Question

我有一个架构，其中所有默认依赖项都是通过Initialize和OnActionExecuting自动注入的。这一切都像魅力一样，因为在运行时（不是测试），默认的控制器激活器将调用这些方法传递正确的具体对象。细

当我的Initialize和OnActionExecuting方法中的自定义依赖项不可注入时，我的问题就开始了。

例：

public class MyController
{
    private IEmailSender emailSender = null;
}

嗯..在运行时emailSender中将为null，除非我将其设置为其他内容。在这种情况下，我最终会得到一些不太好的东西，比如：

public class MyController
{
    private IEmailSender emailSender = null;
    protected override void Initialize(System.Web.Routing.RequestContext requestContext)
    {
         if(this.emailSender == null)
              this.emailSender = new SomeConcreteEmailSender();
    }
}

难看。我不想这样做“if null，instantiate”。

注入IEmailSender的一种更加软化的方式是创建我自己的ControllerActivator，它只能在运行时调用（而不是测试）并自动注入IEmailSender而无需执行此操作“如果”。但我不想为每个需要注入的控制器创建自定义ControllerActivator。

话虽如此，在ASP.NET控制器的自定义依赖注入方面，什么是标准的？

Answer 1

话虽如此，在定制方面，什么是标准 ASP.NET控制器的依赖注入？

构造函数注入：

public class MyController: Controller
{
    private readonly IEmailSender _emailSender;

    public MyController(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    ... actions using the _emailSender here ...
}

对于那些不希望使用现有依赖注入框架的人来说，这里被认为是穷人的依赖注入（请不要使用）（例如，因为他们在一些技术上不识字的白痴指示应该使用什么框架，哪些不是或者懒得编写自定义依赖解析器的公司：

public class MyController: Controller
{
    private readonly IEmailSender _emailSender;

    public MyController(): this(new SomeConcreteEmailSender())
    {
    }

    public MyController(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    ... actions using the _emailSender here ...
}

在ASP.NET MVC控制器上注入自己的自定义依赖项的正确方法是什么？

1 个答案: