RequestServices.GetService()是一个昂贵的操作吗?如果不能在构造函数中获得服务，在方法中使用GetService()是一种不好的做法吗?
注:我是而不是询问依赖注入是否高效。我想问的是，如果在一个方法中使用RequestServices.GetService()(你可以在自定义属性中使用DI)是一个坏主意，或者它在性能上是否等同于"正常"的基于DI的构造函数。
我在Asp中使用自定义属性。asp.net MVC核心应用。在authoizationasync()方法中，我需要访问一个配置设置。由于我的类继承自"Attribute"，所以我不能使用DI将对象传递给构造函数。我使用HttpContext.RequestServices.GetService()方法来获取配置实例。自定义属性可以在大多数请求上运行，所以它不会对性能产生很大的影响。
public async Task OnAuthorizationAsync(AuthorizationFilterContext context)
{
var config = (IConfiguration)context.HttpContext.RequestServices.GetService(typeof(IConfiguration));
...
}
由于该方法对(几乎)每个请求都运行，因此在每个请求时也会解析依赖项。
解析的成本通常不是问题，除非您使用自定义DI提供程序(Autofac)并且具有复杂的类型解析规则。但是微软的DI故意保持简单，这加快了类型解析。
另外，您可能需要考虑依赖生命周期。如果该类型作为暂态类型添加到DI中，则分配&每次解析时创建(即每次执行方法时)
如果它有作用域，则每个请求分配一次。因此，如果多次使用该属性，则在解析类型时只创建和返回一个对象。因此，您为每个请求支付一次费用。
如果它是单例的，它每(应用/DI容器)生命周期分配一次，所以你只付出一次代价。
因此，如果类型很大且创建缓慢，它可能会产生一些开销，但您可以通过在某些if下有条件地解析它来避免它，例如。考虑到所有因素，这几乎肯定是做IO时花费的时间的一小部分，所以我不担心它。