在 asp.net-mvc 中使用依赖注入时，处理单操作依赖的最佳方法是什么？答案

【问题标题】：When using dependency injection in asp.net-mvc, what is the best way to deal with single action only dependencies?在 asp.net-mvc 中使用依赖注入时，处理单操作依赖的最佳方法是什么？
【发布时间】：2016-11-25 05:29:37
【问题描述】：

我有一个 asp.net-mvc 站点，我正在使用 Unity 进行依赖注入，并且我对控制器或模型类的所有依赖都发生在类的构造函数中。

我现在的一个问题是一个类的实例化成本很高，并且它仅用于我的控制器内的单个操作中，因此我不想将它传递给构造函数以在每个其他被调用的操作上实例化那个控制器。我在网上看到的所有例子都有dependencies being injected into the controller like this。

处理这种情况的正确方法是什么，我只需要一个操作的依赖项。现在我只是在我的构造函数类中做“新”，这是我想要避免的（因为我没有抽象和解耦依赖实现）但至少我知道它不会对任何其他操作造成性能影响.

【问题讨论】：

标签： c# asp.net-mvc dependency-injection inversion-of-control

【解决方案1】：

您的应用程序组件的创建应该是fast and their constructors should be simple。任何繁重的初始化都应该推迟。

当由于某些遗留代码的存在而无法实现时，您应该将组件包装在同一接口的代理实现后面。例如：

public class LazyServiceProxy : IService
{
    private readonly Lazy<IService> service;
    public LazyServiceProxy(Lazy<IService> service) {
        this.service = service;
    }

    void IService.Method(object param1) => this.service.Value.Method(param1);
}

还要注意，您的依赖项仅在单个操作中使用这一事实表明您的控制器的操作方法之间的内聚度较低。低凝聚力是Single Responsibility Principle (SRP) 违规的标志。 SRP 规定每个类都应该有一个单一的职责，因此这可能意味着将操作及其依赖项移至其自己的控制器是件好事。虽然根据共同的 url 前缀（例如 /customers/action）将操作分组在一起是一种常见的做法，但 MVC 完全允许您将操作拆分为多个控制器，同时保持其原始 url。

【讨论】：

谢谢史蒂文。我同意你上面的观点。就“MVC 完全允许您将操作拆分为多个控制器，同时保持其原始 url”而言。你在谈论重定向吗？