0

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

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

示例：

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自动注入而无需执行此“if”。但我不想ControllerActivator为每个需要注入的控制器创建自定义。

话虽如此，对于 ASP.NET 控制器的自定义依赖注入，什么被认为是标准的？

4

1 回答 1

3

话虽如此，对于 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 ...
}
于 2012-09-12T14:55:45.717 回答