为什么依赖注入总是在构造器上注入，这样真的好吗?
0
[待解决问题]
一直有这个疑问，构造器注入的服务，用都用不完，完全就是浪费资源
如图，第一种构造器注入，被动获取服务，不管执行Index页面还是执行PageTwo页面都会产生 dep1和dep2的服务，在这里至少多了一个变量，一个对象的实例
第二种，我不采用被动获取方式，我使用主动注入，我执行Index的时候只使用dep1，执行PageTwo的时候用dep2，不会造成资源浪费
在举个例子，你是一个便利店，你要进货，对方也不知道这次需要什么，一次把水，面包都送过来，然而到了你说你只用水就好了，这样真的合适吗？
在看别人写的代码的时候，一个构造器上十几个服务，一个服务构造器又搞十几个，根本用不完
我发这个问题仅仅限于讨论，依赖注入固然是好，但是总倡导构造器注入真的就是好的吗？
所有回答(5)
0
有的时候需要为代码简洁，需要牺牲一点性能，你这个性能损失相当于我使用 try catch 捕获业务异常一样。就损失很小，因为只是实例化，并不是执行大量操作而已
我觉得构造器注入，注入一两个还是比较好的，注入3 5个以上就显得很难看了，又长又多，一个不经意，一次就会产生几十个无用的对象
不如主动获取服务的方式，哪里用在哪里获取，代码也不会显得不好看呢
虽然浪费的东西少，但是浪费还是浪费了，个人感觉，不好，不干净
0
[Route("api/[controller]/[action]")]
[ApiController]
public class TestController : ControllerBase
{
[HttpPost]
public void Test([FromServices]TestService service)
{
}
}
我会这样用。
我也这么用过，后面在父类写了一个方法，专门用于获取服务，结果被说了，哎！！
@万花从中一枝梅: 为什么被说了，这样有啥弊端？
0
第三方支持更多的注入方式（例如Autofac）
0
在java中依赖注入也是也存在如上所说的自动和主动注入，构造方法注入在容器启动阶段进行自动注入，不会考虑对象是否用到，如果存在大量注入对象当然会出现代码冗余，性能浪费，但是它有一个好处是稳定的，一旦单例化后基本不会发生改变；而主动注入也就是我们的Setter注入也是当需要的时候才会进行注入，这样是节省了不必要的资源浪费，但是它是不稳定的，也就是说这个对象是可能改变的。所以，一般还是视情况而定吧，也不能说一定要构造方法注入，既然有其他的方式存在一定是补足而不是淘汰。看到题主问题与java中的依赖注入相似，只能从java角度回答一下。
0
现实情况是->没有区别.
要看对象生命周期.
怎么就没有区别了呢
构造器多余的接口也是要被实例化的，那不就是资源浪费了么？
除非你全部是单列，但是事实上肯定很多都不是单例
其实我觉得更难受的是超过的接口卸载构造器上，看起来难以识别
我觉得你的方法挺好的
– 会长 4年前