Коли не використовувати Spring для придушення бобів?

Я намагаюся зрозуміти, що було б правильним використанням Spring. Не синтаксично, а в терміні своєї мети. Якщо хтось використовує Spring, то чи повинен Spring код замінити весь код екземпляра бобів? Коли вживати або коли не використовувати Spring, щоб інстанціювати боби?

Можливо, наступний зразок коду допоможе вам зрозуміти мою дилему:

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 є невідповідним для вказаного вами випадку використання. Весна краще використовувати для управління зовнішніми залежностями (наприклад, підключення з'єднання JDBC до DAO) або конфігурацій (наприклад, вказуючи, який тип бази даних використовувати). У вашому прикладі, якщо тип квасолі може змінитися, то ви використовуєте інтерфейс, щоб вказати квасоля, а інстанціювати квасоля за допомогою Factory. Ви б використовували Spring, щоб вказати, яку фабрику використовувати, і введете її в клас, необхідний для екземпляра бобів. Тоді ви можете мати кілька різних заводів, які створили декілька різних типів бобів (які підтримували інтерфейс бобів) і налаштувати відповідний під час встановлення (або оновлення) часу.

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

Якщо це боб , ви повинні дозволити Spring побудувати його (за винятком того, що ви можете поставити заводський боб - я використовував це там, де мені потрібно було повернути певний підклас, залежний від властивості системи, - і вам слід ознайомитися з документацією щодо @Configurationта @Beanприміток якщо ви це робите). Якщо це не боб, а просто звичайний старий об'єкт Java, вам не потрібно використовувати Spring, щоб зробити його взагалі. POJO корисні, але не отримуватимуть ін'єкцій залежностей, AOP обгортки тощо, оскільки це те, що весна додає вам.

Фундаментальне рішення полягає в тому, чи це дійсно боб, чи просто якийсь звичайний об'єкт, який трапляється слідувати деяким умовам бобів (наприклад, іменування методів). Я не можу здогадатися, що насправді так, з невеликого прикладу, який ви навели.

Я можу помилитися з експертами, будь ласка, виправте.

Вся концепція Bean у весняному контексті - Spring Container піклується про об’єкт. Це народження, це сфера смерті життєвого циклу тощо ... Це як наглядач за об'єктом. Додаток, який потребує цього, вводить його.

Тому, приймаючи рішення під час проектування свого модуля, завжди думайте, чи хочете Ви доглядати за рамками Spring, чи це простий об’єкт, життєвий цикл якого укладений у метод.

Як було запропоновано раніше, об'єкти дао jms в черзі, об'єкти тощо важкі і краще залишити експерту, який має Spring Framework, щоб піклуватися про нього.