Wiosna - zamieszanie związane z konfiguracją?

Gdzieś czytałem, że Spring oferuje wygodę w porównaniu z konfiguracją. Ale ludzie z Spring wprowadzają tak wiele zmian w konfiguracji, że teraz jestem naprawdę zdezorientowany, jeśli chodzi o użycie konfiguracji xml lub adnotacji.

Chciałbym, aby ktokolwiek zasugerował pewną metodologię lub praktyczną zasadę przy użyciu XML i adnotacji.

Przykłady w SO pokazują, że wielu początkujących, takich jak ja, jest zdezorientowanych konfiguracją.

• link-1

  Wydaje mi się, że nie rozumiem funkcjonalności <context:annotation-config>i <context:component-scan>.

  Z tego, co przeczytałem, wydaje się, że obsługują różne adnotacje (@Required, @Autowired itp. Vs @Component, @Repository, @Service itp.), Ale także z tego, co przeczytałem, rejestrują te same klasy postprocesora komponentu bean.

  Żeby mnie jeszcze bardziej zdezorientować, istnieje annotation-configatrybut na <context:component-scan>...

• link 2

  Nadal mam tag skanowania komponentu:

  <context:component-scan base-package="com.mycompany.maventestwebapp" />

  ale mam też inny tag (wyglądający jak podobne zadanie), ten:

  <annotation-driven />

  Jaka jest różnica między tymi dwoma tagami? Inną „dziwną” rzeczą jest to, że poprzedni przykład (który nie używa znacznika opartego na adnotacjach) jest bardzo podobny do projektu utworzonego przez STS przy użyciu projektu szablonu Spring MVC, ale jeśli usunę znacznik oparty na adnotacjach z jego konfiguracji plik projekt nie działa i wyświetla mi następujący błąd: HTTP Status 404 - ...

Spring 3.2 nie potrzebuje już cglib do proxy, ale niższe wersje używają cglib. Cytat z bloga springsource

Aby wygenerować takie proxy, Spring używa biblioteki innej firmy o nazwie cglib. Niestety ten projekt nie jest już aktywny. Wiosną 3.2 jest bardzo prawdopodobne, że Spring będzie domyślnie używać Javassist.

Czy to wystarczy, aby zasugerować, że Wiosna jest zamieszaniem w kwestii konfiguracji?

Wiosna ma na celu zapewnienie ram, w których istnieje „konwencja w sprawie konfiguracji”. Jednak w rzeczywistości aplikacje Spring wymagają pewnej konfiguracji.

We Spring 2.5.x i wcześniejszych wersjach powszechnym idiomem było zapewnienie tej konfiguracji przez XML. W Spring 3.0+ idiomatycznym sposobem jest stosowanie adnotacji (coś, co zachęca także Java EE6 / 7).

Na marginesie, może być zabawne (zasmucenie?) Zobaczyć jednostkę JPA z adnotacjami, raczej łatwo jest dodać adnotacje 4+ w jednym polu ...

<annotation-driven />

Musisz określić schemat XML, skąd pochodzi.

Najprawdopodobniej jest to w kontekście strategii obsługi transakcji JPA podczas definiowania menedżera transakcji (patrz 9.5.6. Korzystanie z @Transactional w dokumentach Springa)

Po zdefiniowaniu obsługi transakcji opartej na adnotacjach - Spring AOP automatycznie tworzy aspekty dla twojej metody, aby rozpocząć (lub sprawdzić istniejącą) transakcję przed wywołaniem metody, a następnie zatwierdzić (lub wycofać w przypadku wyjątku) po zakończeniu ivokacji metody.

Odkryłem, że tworzenie IoC / Bean oparte na adnotacjach jest przydatne, gdy masz implementację singleton, ale może zajść potrzeba jej zamiany.

W przeciwieństwie do sytuacji, w której może być konieczne wielokrotne użycie fasoli z różnymi zależnymi klasami / instancjami.

W takich przypadkach deklaruję komponent bean w konfiguracji i zwykle wykonuję wstrzyknięcie konstruktora jakiejkolwiek zależności, której potrzebuję. Następnie, w klasie, która będzie używać wspomnianej fasoli, ja, @Autowirea następnie @Qualifier("")- tak powinny działać fabryki.

Singleton to metoda fabryczna, która zwraca tylko 1 wynik. Kiedy to nie jest wygodne, musisz to pomieszać.

Jeśli chodzi o użycie skanu komponentów vs. Zasadniczo wyrażam się jasno na temat skanowania komponentów pakietu. W ten sposób mogę stworzyć inny kontekst aplikacji do testowania, w którym mogę wyśmiewać zewnętrzne zależności (np. Db), jednocześnie testując resztę mojej konfiguracji IoC.

Ponadto nie mam @Componentkodu biblioteki w moim projekcie. Nigdy nie wiesz, kiedy / jak będziesz musiał użyć tam fasoli, a jeśli @Componenttak, możesz przypadkowo podnieść ją w skanie i ograniczyć jej ponowne użycie. W takich przypadkach ogólnie mam kontekst aplikacji zdefiniowany w bibliotece z kilkoma przydatnymi domyślnymi deklaracjami komponentu bean, które mój główny projekt MOŻE uwzględnić w imporcie do swojego kontekstu aplikacji.

Żadna religia tutaj. Po prostu doświadczenia do przekazania

Spring oferuje opcje, pierwotnie było tylko okablowanie oparte na XML. Później dodano okablowanie oparte na adnotacjach.
Jest teraz możliwe (i wiele osób to robi), aby użyć kombinacji obu.
Istnieje duża dokumentacja dołączona do Spring i / lub do pobrania ze strony internetowej springsource. Jest profesjonalne szkolenie (nigdy tego nie zrobiłem, nie mogę za niego ręczyć) i całkiem sporo dobrych książek (lubię APress 'Pro Spring, wybierz odpowiednią wersję dla wersji Spring, którą zatrudniasz).