Kiedy nie używać Spring do tworzenia instancji fasoli?

Próbuję zrozumieć, jakie byłoby właściwe użycie wiosny. Nie składniowo, ale pod względem celu. Jeśli używasz Springa, to czy kod Spring powinien zastąpić cały kod instancji komponentu bean? Kiedy używać, a kiedy nie używać Spring, aby utworzyć instancję fasoli?

Może być następujący przykładowy kod, który pomoże ci zrozumieć mój dylemat:

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

Jeśli skonfiguruję Spring, stanie się on mniej więcej taki:

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

Osobiście uważam, że użycie wiosny jest tutaj niepotrzebnym kosztem, ponieważ

1. Kod prostszy do odczytania / zrozumienia.
2. To naprawdę nie jest dobre miejsce na Dependency Injection, ponieważ nie spodziewam się, że będzie wiele / różnorodna implementacja ClassA, którą chciałbym mieć swobodę zastąpienia przy użyciu konfiguracji Spring w późniejszym czasie.

Czy myślę poprawnie? Jeśli nie, to gdzie się mylę?

Masz rację, Spring jest nieodpowiedni dla wymienionego przypadku użycia. Spring lepiej nadaje się do zarządzania zależnościami zewnętrznymi (np. Podłączaniem połączenia JDBC do DAO) lub konfiguracjami (np. Określaniem, jakiego typu bazy danych użyć). W twoim przykładzie, jeśli typ fasoli mógł ulec zmianie, użyłbyś interfejsu, aby określić fasolę i utworzyć instancję fasoli za pomocą Factory. Używałbyś Springa, aby określić, której fabryki użyć, i wstrzyknąłeś ją do klasy, która potrzebowała utworzyć instancję ziaren. Następnie można mieć kilka różnych fabryk, które utworzyły kilka różnych rodzajów ziaren (wszystkie obsługują interfejs komponentu bean) i skonfigurować tę odpowiednią w momencie instalacji (lub aktualizacji).

Używałbym sprężyny (lub innego systemu DI) między warstwami, bezpośredniej instancji w warstwach.
Tak więc klasa, która tworzy komponent bean, który opuszcza zakres tej klasy, do jakiegoś (funkcjonalnie) systemu zewnętrznego, ewentualnie zdefiniowanego przez ten system lub jakąś warstwę komunikacyjną, zostałaby utworzona za pośrednictwem DI. Kolejny komponent bean stworzony wyłącznie do użytku wewnętrznego w warstwie aplikacji jest tworzony bezpośrednio, zarówno ze względu na przejrzystość kodu, jak i (w dużych systemach równie ważne) ze względu na wydajność.

Jeśli jest to fasola , powinieneś pozwolić Springowi ją zbudować (z wyjątkiem tego, że możesz dostarczyć fasolę fabryczną - wykorzystałem ją tam, gdzie potrzebowałem zwrócić konkretną podklasę zależną od właściwości systemu) - i powinieneś zapoznać się z dokumentacją @Configurationi @Beanadnotacjami jeśli to robisz). Jeśli nie jest to fasola, ale zwykły stary obiekt Java, nie musisz wcale używać Springa. POJO są przydatne, ale nie dostaną zastrzyku zależności, opakowań AOP itp., Ponieważ są to rzeczy, które Spring dodaje dla ciebie.

Podstawową decyzją jest to, czy tak naprawdę jest to fasola, czy tylko zwykły obiekt, który spełnia pewne konwencje bean (np. Nazewnictwo metod). Nie mogę zgadnąć, co tak naprawdę jest w przypadku małego przykładu, który podałeś.

Mogę się mylić, eksperci, poprawcie.

Cała koncepcja Bean w kontekście wiosennym polega na tym, że Spring Container dba o przedmiot. To narodziny, śmierć w całym cyklu życia itp. To tak, jakby to był dozorca obiektu. Aplikacja, która tego potrzebuje, wstrzykuje go.

Tak więc, podejmując decyzję podczas projektowania modułu, zawsze zastanów się, czy chcesz zająć się frameworkiem Spring, czy jest to prosty obiekt, którego cykl życia jest zamknięty w metodzie.

Jak wcześniej sugerowano obiekty dao, kolejki Jms itp. Są ciężkie i lepiej pozostawić je ekspertowi, który jest Spring Framework.