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

Question

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

当我有一个无法在 Initialize 和 OnActionExecuting 方法中注入的自定义依赖项时，我的问题就开始了。

示例：

public class MyController
{
    private IEmailSender emailSender = null;
}

嗯.. 在运行时emailSender 将为空，除非我将其设置为其他值。在这种情况下，我会得到一些不太好的东西，像这样：

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

丑陋。我不想做这种“如果为空，则实例化”的事情。

注入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 ...
}