反对控制反转容器的论点
反对控制反转容器的论点
看起来似乎每个人都在朝着IoC容器的方向发展。我试图理解它一段时间了，尽管我不想成为错误地在高速公路上开错道的人，但对我来说它仍然没有通过常识的测试。让我解释一下，如果我的论点有误，请纠正/启发我：
我了解到：IoC容器旨在在组合不同的组件时使您的生活更轻松。这是通过a)构造函数注入，b)设置器注入和c)接口注入来实现的。然后通过编程方式或由容器读取的文件进行"连接"。然后按名称召唤组件，需要时手动进行转换。
我不明白的是：
为什么要使用一个对语言不习惯的不透明容器，当您可以通过正确设计组件（使用IoC模式，松耦合）以（在我看来）更清晰的方式来"连接"应用程序呢？这种"托管代码"如何获得非平凡的功能？（我听说过一些与生命周期管理有关的提及，但我并不一定理解这与自己动手相比有何优势/更快。）
为什么要经过存储组件在容器中的所有步骤，以一种与语言不习惯的方式进行"连接"，使用等同于"goto标签"的东西来调用组件，并通过手动转换失去静态类型语言的许多安全性好处，当您可以通过不这样做来获得等效的功能，并使用现代面向对象语言提供的所有抽象功能，例如针对接口进行编程？我的意思是，实际需要使用该组件的部分在任何情况下都必须知道它们在使用它，而在这里您可以使用最自然、习惯的方式进行"连接" - 编程！
控制反转（IOC）的出现是为了将创建依赖对象的责任从主对象中移除，并委托给第三方框架。我通常使用Spring作为我的IOC框架，它带来了许多好处。
1. 促进面向接口编程和解耦
IOC的关键好处是促进和简化解耦。您可以始终在主对象中注入一个接口，然后使用接口方法来执行任务。主对象不需要知道分配给接口的依赖对象是哪个。当您想要使用不同的类作为依赖时，只需在配置文件中将旧类替换为新类，而不需要更改一行代码。现在您可以争论说，这可以在代码中使用各种接口设计模式来实现。但是IOC框架使这变得轻而易举。因此，即使作为新手，您也可以成为利用各种接口设计模式（如桥接、工厂等）的专家。
2. 清晰的代码
由于大部分对象的创建和对象生命周期操作都委托给IOC容器，所以您不需要编写繁琐重复的代码。因此，您可以编写更清晰、更简洁、更易于理解的代码。
3. 单元测试
IOC使单元测试变得容易。由于您留下的是解耦的代码，您可以轻松地对解耦的代码进行独立测试。而且，您可以轻松地在测试用例中注入依赖项，并查看不同组件的交互方式。
4. 属性配置器
几乎所有的应用程序都有一些属性文件，其中存储了应用程序特定的静态属性。现在，为了访问这些属性，开发人员需要编写读取和解析属性文件并将属性存储在应用程序可访问的格式中的包装器。现在，所有的IOC框架都提供了一种在特定类中注入静态属性/值的方法。所以这又变得非常简单。
以上是我能立即想到的一些观点，我相信还有更多。
IoC容器的出现是因为使用IoC容器是IoC的一个子集，而不是整个IoC的全部。实际上，即使不使用IoC容器框架，也可以将IoC作为设计构造使用。在这个上下文中，最简单的IoC可以被表述为“供应，而不是实例化”。只要对象不依赖其他对象的实现，而是要求提供已实例化的实现，那么就是在使用IoC，即使不使用IoC容器框架。
关于面向接口的编程，使用IoC容器确实是面向接口编程的一种方式。整个思想，至少在我使用的方式中，是将接口（类型）与实现（注入的类）分离。依赖于接口的代码只针对接口编程，而接口的实现在需要时被注入。
例如，可以有一个返回类型为Foo的数据存储的IFooRepository。所有需要这些实例的代码从一个类型为IFooRepository的提供对象中获取它们。在其他地方，创建一个FooRepository的实现，并配置IoC在任何需要IFooRepository的地方提供它。这个实现可以从数据库、XML文件、外部服务等获取它们，不管它们来自哪里，控制权都被颠倒了。使用Foo对象的代码不关心它们来自哪里。
显而易见的好处是，可以随时替换这个实现。可以用测试版本替换它，根据环境改变版本等。但要记住，您在任何给定时间也不需要具有接口到实现的1对1的比例。
例如，我曾经在以前的工作中使用过一个代码生成工具，它将大量的DAL代码输出到一个类中。将其拆分开会很麻烦，但配置它以在特定的方法/属性名称中输出所有代码并不麻烦。所以我为我的存储库编写了一堆接口，并生成了这个实现了所有接口的类。对于那个生成的类来说，它很丑陋。但是我的应用程序的其余部分并不关心，因为它将每个接口都视为自己的类型。IoC容器只为每个接口提供相同的类。
我们能够迅速启动并且没有人在等待DAL的开发。当我们继续在使用接口的领域代码中工作时，一位初级开发人员负责创建更好的实现。稍后将这些实现替换掉，一切都很好。
正如我之前提到的，所有这些都可以在没有IoC容器框架的情况下完成。真正重要的是模式本身。谢谢你的回答David！我同意使用IoC模式是重要的，可以创建出更好的API。我的“困惑”在于使用框架和容器 - 我只是不明白在一个对你来说几乎是虚拟机的地方存储对象实例和“连接”你的应用程序的意义。
反对控制反转容器的论点出现的原因是：
1. 对象组合的角度来看，容器的好处可能微不足道，因为任何第三方都可以连接松散耦合的组件。
2. 一旦超出了玩具场景，连接协作者的第三方就必须承担更多的责任，不仅要负责组合，还可能存在资源泄露的问题，因此必须承担生命周期管理的角色。
3. 当组合各种实例范围时，使用共享和私有服务的组合，甚至将某些服务作用域限定为特定环境（比如Web请求），问题变得复杂起来。使用贫民版的DI编写所有这些代码当然是可能的，但这并不增加任何业务价值，纯粹是基础设施。
4. 这样的基础设施代码构成了一个通用子域，因此创建一个可重用的库来解决这些问题是非常自然的。这就是DI容器的作用。
5. 大多数我所知的容器不使用名称进行自动连接，而是使用自动连接，它将来自构造函数注入的静态信息与容器的接口到具体类的映射配置相结合。简而言之，容器本身就能理解这些模式。
6. DI容器不是DI所必需的，但它确实非常有帮助。
解决方法：
1. 将通用功能抽象成可重用的组件。
2. 学习和了解DI容器的工作原理和使用方法。
3. 根据实际需求选择合适的容器，并使用自动连接功能简化开发过程。
4. 根据平台选择适合的容器，如Java的Spring或.NET的Spring.NET。
5. 了解不同平台的差异，选择适合自己项目需求的容器。
6. 更新Java EE版本，使用最新的Java EE容器，或选择与需要的功能和易用性相匹配的容器。
在解决这些问题的过程中，应该遵循最佳实践和标准规范，以确保代码的可维护性和可扩展性。