什么时候不使用Spring实例化bean？

我试图了解什么是Spring的正确用法。不是语法，而是目的。如果使用Spring，那么Spring代码是否应该替换所有bean实例化代码？什么时候使用或何时不使用Spring来实例化bean？

可能以下代码示例将帮助您理解我的困境：

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = new ClassA();
    ca.setName(name);
    caList.add(ca);
}

如果我配置Spring，它将变为：

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
    ca.setName(name);
    caList.add(ca);
}

我个人认为在这里使用Spring是不必要的开销，因为

1. 该代码更易于阅读/理解。
2. 这并不是真正的依赖注入的好地方，因为我不希望会有的/可变的实现ClassA，我希望以后可以自由使用Spring配置进行替换。

我认为正确吗？如果没有，那我要去哪里错了？

没错，Spring不适合您列出的用例。Spring更适合用于管理外部依赖项（例如将JDBC连接插入DAO）或配置（例如指定要使用的数据库类型）。在您的示例中，如果易于更改Bean类型，那么您将使用接口来指定Bean，并使用Factory实例化Bean。您将使用Spring指定要使用的工厂，并将其注入实例化bean所需的类中。然后，您可能有几个不同的工厂，它们创建了几种不同类型的Bean（都支持Bean接口），并在安装（或更新）时配置了合适的工厂。

我会在层之间使用Spring（或另一个DI系统），在层内直接实例化。
因此，将通过DI创建一个类，该类创建一个将bean的类的范围留给某个（功能上的）外部系统（可能由该系统或某个通信层定义）的类。出于代码清晰和（在大型系统中同样重要）性能方面的考虑，直接创建了另一个纯粹供应用程序内部内部使用的bean。

如果是bean，则应让Spring对其进行构建（除非您可以提供工厂bean，但我曾在需要返回依赖于系统属性的特定子类的地方使用过该bean），并且应查阅@Configuration和@Bean注释上的文档。如果您正在这样做）。如果它不是bean，而只是一个普通的Java对象，则根本不需要使用Spring即可。POJO很有用，但不会获得依赖项注入，AOP包装器等，因为这些是Spring为您添加的东西。

基本的决定是它是否真的是一个bean，或者仅仅是某个遵循某些bean约定（例如，方法命名）的普通对象。我无法从您提供的小示例中猜出是哪种情况。

我可能是错误的专家，请纠正。

Spring上下文中Bean的整个概念是Spring Container正在照顾对象。它的诞生，范围生命周期的死亡等等。这就像对象的看守。需要它的应用程序将其注入。

因此，在模块设计过程中做出决定时，请始终考虑是要让Spring框架保重还是它是一个生命周期包含在方法中的简单对象。

如先前建议的dao对象，jms将对象等排队很重，最好由Spring框架的专家来处理。