几周以来，我一直在阅读 Spring in Action 一书以了解 Spring 框架。我有大约 2 年的编程经验，主要是在 java 中，在 Ruby 和 Python 中到处都有一些干扰。
在阅读了前几章之后，我并没有完全明白 Spring 中的依赖注入有什么大不了的。我期待一个 AHAAA 时刻，但还没有完全体验到。我确定我错过了一些重要的东西。
为什么我想在 xml 中连接我的 bean 而不是用旧的方式实例化它们= new myclass();
我知道我可以通过构造函数参数和属性在 xml 中连接 bean，也可以在 spring 中配置数据源，这样我就可以在 xml 文件中隐藏连接细节。但为什么？这还有更多，尤其是在良好的软件设计方面。有人能解释一下大事吗？
三个词：控制反转
简而言之：一旦你实例化“好的旧方法”，你就会创建紧密耦合，例如：你的控制器依赖于特定的模板引擎，你的实体依赖于具体的数据库层等等。这就是你想要防止的事情以及在哪里依赖注入容器（DIC）非常方便。它管理您的服务，您不必再关心具体的实现，只要它们实现相同的接口即可。
想象一个简单的存储层类InMemoryLayer，在需要时由您实例化。现在你想把它换成一个很棒的新开源 github 解决方案，叫做SuperSecretRemoteCloudLayer. 通常，您现在会在您选择的 IDE 中点击“搜索和替换”，并将所有出现InMemoryLayer的SuperSecretRemoteCloudLayer. 但这不是很方便而且很容易出错，你为什么要手动完成所有这些艰苦的工作呢？DIC 可以为您做到这一点，您需要注意的是两者都*Layer实现相同的接口（因此您的应用程序不会中断）。
Spring 的大事更多是关于依赖注入，而不是基于 XML 的配置。正如其他人所指出的，Spring 已经远离基于 XML 的配置。但是 DI 是 Spring 的核心。
啊哈是 DI 提供了一种不同的模型来将组件链接在一起。不是组件直接相互创建（因此紧密耦合），而是组件停止这样做，并且您从中心位置注入链接。事实证明，这尤其有助于测试和事务管理。
除非您不得不以艰难的方式做事，否则您不会真正欣赏 Spring。在没有连贯框架的情况下维护多个大型项目的艰难方法。如果您有 4 个大型企业级应用程序，它们都有自己的启动方式和管理资源的方式，那么您会很头疼。如果您知道每个应用程序都使用spring，那么只需查找应用程序上下文xml！这也使得为不同的环境和测试用例设置新的上下文变得非常容易，所有这些都不会破坏您的代码库。