例如，如果我有一个ContainingClass和DependencyClass（及其接口）：当使用Spring来管理/实例化一个bean
public class ContainingClass {
IDependencyClass d;
public ContainingClass(IDependencyClass d){
this.d = d;
}
}
他们去耦不够。在这个时候，显然我们可以使用构造函数来连接它们。为什么要在春天的环境中定义它们呢？
你们可以谈谈使用spring容器来管理bean有什么优势吗？先谢谢你。
另外：如果我们太多地使用spring容器，我认为维护容器和重构代码将是相当困难的。不是吗？
容器通常用作负责实例化所有对象的顶级实体。它解决了你最终必须解决的问题，必须将新的所有对象放在一起，并将应用程序变为现实。
在依赖注入框架之前，人们通过分离负责将对象连接在一起的Factory类来解决此问题。在较大的应用程序中，这导致了许多无用的样板类，它们只对一组对象调用“新”。 Spring允许你基本上从你的应用程序中删除这个问题。
对于非常小的应用程序，您可能不会感到必须构建应用程序，并且使用弹簧容器可能是矫枉过正的。但对于大型应用程序，使用像Spring这样的容器可以减少样板切割，并且可以更容易地将应用程序的各个部分连接起来以用于测试目的，而不必每次都将完整的应用程序上下文连接在一起。
此外，依赖注入容器鼓励某种编程风格，这种风格通常会导致更可测试的系统，即注入依赖关系而不是在构造函数中新建它们。这使您可以轻松将模拟对象替换为数据库连接之类的东西。
对于您的具体问题，答案是您的应用程序中必须存在其他类，它知道如何实例化ContainingClass以及在哪里可以找到IDependencyClass的实例。春天可以为你做这件事，或者你必须写一个自己做的类。
这里有三点考虑：
是否有意义首先使用Spring？对于具有可能的类和包的大规模Java Web应用程序 - 是（假设您考虑了任何可能的替代方案）。如果它只是几行Java应用程序 - 可能不会。
一致性。如果项目的其余部分是Spring的核心部分，并将其配置为XML中的bean，那么您可能会坚持这一点。如何做其他事情？你是从头开始使用Spring MVC吗？然后坚持这种模式，你可以在Spring文档中看到大量的例子。
你的两个类如何分离。例如，如果您的ContainingClass是服务层上的服务，而您的IDependencyClass是数据访问层上的DAO，那么很可能我会分别配置它们并让Spring进行注入。特别是，当我计划在另一个环境中使用IDependencyClass或者如此设计时，它可以在不知道ContainingClass的情况下切换（例如，在底层访问层发生变化的情况下）。
此外，可以考虑使用基于注解的配置，即减少了对大幅单独的XML文件的必要性，并使得它（如果使用得当）更容易通过代码来跟踪具有对XML和Java代码之间进行切换。