Когда не использовать Spring для создания экземпляра bean-компонента?

Я пытаюсь понять, как правильно использовать Spring. Не синтаксически, но по назначению. Если кто-то использует Spring, то должен ли Spring-код заменить весь код создания бина? Когда использовать, а когда не использовать 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-компонента и создания экземпляров bean-компонентов с использованием Factory. Вы бы использовали Spring, чтобы указать, какую фабрику использовать, и внедрили это в класс, необходимый для создания экземпляров bean-компонентов. После этого вы могли бы иметь несколько разных фабрик, которые создавали несколько разных типов bean-компонентов (которые все поддерживали интерфейс bean-компонента), и настраивать этот подходящий во время установки (или обновления).

Я бы использовал Spring (или другую систему DI) между слоями, прямое создание экземпляров внутри слоев.
Таким образом, класс, который создает компонент, который оставляет область действия этого класса, некоторой (функционально) внешней системе, возможно определенной этой системой или некоторым уровнем связи, будет создан через DI. Другой bean-компонент, созданный исключительно для внутреннего использования на уровне приложения, создается напрямую как для ясности кода, так и (в больших системах, что не менее важно) с точки зрения производительности.

Если это фасоль , вы должны позволить Spring построить его ( за исключением вы можете поставить заводскую боб - я использовал что там , где мне нужно , чтобы вернуть конкретный подкласс зависит от системного свойства - и вы должны обратиться к документации на @Configurationи @Beanаннотации если ты это делаешь). Если это не bean-компонент, а просто обычный Java-объект, вам не нужно использовать Spring для его создания. POJO полезны, но не будут получать инъекцию зависимостей, оболочки AOP и т. Д., Так как это то, что Spring добавляет для вас.

Фундаментальное решение заключается в том, действительно ли это бин или просто какой-то обычный объект, который следует некоторым соглашениям бина (например, именование методов). Я не могу догадаться, что на самом деле имеет место из небольшого примера, который вы дали.

Я могу ошибаться, эксперты, пожалуйста, поправьте.

Вся концепция Bean в контексте Spring заключается в том, что Spring Container заботится об объекте. Это рождение, это сфера жизненного цикла, смерть и т. Д. Это как будто смотритель объекта. Приложение, которое нуждается в этом, вводит его.

Поэтому, принимая решение во время проектирования вашего модуля, всегда думайте, хотите ли вы, чтобы Spring Framework позаботился об этом, или это простой объект, жизненный цикл которого заключен в методе.

Как уже предлагалось ранее, объекты dao Объекты jms queues и т. Д. Тяжелы и лучше оставить их специалисту, который является Spring Framework, чтобы позаботиться об этом.