在MVC应用程序中使用IoC框架有什么用？
我试图理解像StructureMap这样的IoC框架的使用，但我不禁想到这些“设计模式”只是无意义，使代码变得更加复杂。
让我先举一个例子，我认为IoC有点用处。
我认为在处理MVC框架中控制器类的实例化时，IoC可能很有用。 在这种情况下，我正在考虑.NET MVC框架。
通常，控制器类的实例化由框架处理。 这意味着您无法将任何参数传递给控制器类的构造函数。 这就是IoC框架可以派上用场的地方。 在IoC容器中的某处，您可以指定在调用控制器类时应该实例化哪个类并将其传递给控制器constructor 。
当您想要对控制器进行unit testing时，这也很方便，因为您可以模拟传递给它的对象。
但就像我说的，我可以理解为什么人们想将它用于控制器类。 但不是在那之外。 从那以后，您可以简单地执行正常的dependency injection 。
但为什么不简单地这样做：
public class SomeController { public SomeController() : this( new SomeObj() ) { } publiv SomeController(SomeObj obj) { this.obj = obj; } }
现在您不必使用任何第三方IoC框架，这也意味着更低的学习曲线。 既然您不必深入了解该框架的规范。
您仍然可以在unit testing中模拟对象。 所以也没问题。
你唯一可以说的是，“但现在你的class级与 SomeObj 紧密 SomeObj ”。 这是真的。 但谁在乎！？ 这是一个控制器类！ 我永远不会重复使用那个类..那么为什么我要担心这种紧耦合……？ 我可以模拟传递给它的对象。 这是唯一重要的事情。
那我为什么要打扰使用IoC呢？ 我真的错过了这一点……？ 对我来说，IoC模式只是一些被高估的模式。 为您的应用程序添加更多复杂的图层……
你问了一个很好的问题，在你的例子中我会说IoC会/可能有点过分，但只要考虑你的代码扩展到以下内容，然后你就可以开始看到让IoC为你做这一切的好处。
public class SomeController { public SomeController() : this( new SomeObj(new configuration(), new SomethingElse(new SomethingElseToo())) ) { } publiv SomeController(SomeObj obj) { this.obj = obj; } }
IoC容器可以为您做多件事。
显而易见的是提供依赖项的实现，这在其他地方是有意义的，而不仅仅是在控制器中 – 如果您决定用SomeObj2替换SomeObj2 ，您可以在一个地方而不是57个地方执行。
另一个是处理生命周期问题，即您可以指定对象的范围（单例，每个线程，每个请求，瞬态……）。
此外，IoC容器可以设置您的可选依赖项（即属性注入），这比写这个更容易：
var svc = new Service(new MyRepository()) svc.Logger = logger; svc.XY = xy
以及这里陈述的所有好理由： 为什么我需要一个IoC容器而不是直接的DI代码？
但谁在乎！？ 这是一个控制器类！ 我永远不会重复使用那门课程。
这是一个很好的观点，但如果你有不同的生命周期的嵌套依赖关系，请考虑代码有多清晰。 例如，您可以拥有一些应用程序级单例，需要“按请求”等等。 IoC使您的代码更清晰，易于修改。