ZAWWW-2st1.2-w12.tresc-1.0-Slajd4
Ideologia architektury Spring
Konstrukcja architektury Spring wynika ze zbioru założeń, które można śmiało nazwać ideologią architektury Spring. Podstawowy zarzut kierowany przez autorów pod adresem technologii Java EE to nadmierne skomplikowanie i zdecydowanie zbyt duża liczba interfejsów i komponentów. Wiąże się z tym konieczność pisania bardzo dużej ilości kodu, który nie wykonuje żadnego przetwarzania, a służy tylko i wyłącznie sklejaniu warstw i komponentów. Największą niechęć autorzy architektury Spring wykazują w stosunku do komponentów encyjnych, które uważają za przestarzałe, zdecydowanie zbyt złożone, używane w sytuacjach, w których proste komponenty JavaBean są zupełnie wystarczające. Podsumowując, autorzy architektury Spring uważają komponenty encyjne za prawie zbędne, czyniąc wyjątek tylko dla aplikacji, których wewnętrzna architektura jest faktycznie rozproszona. Architektura Spring jest oparta praktycznie tylko na interfejsach, mechanizm dziedziczenia jest używany bardzo rzadko. Jest to świadomy wybór projektowy, mający na celu zwiększenie niezależności między aplikacją a Spring API oraz między poszczególnymi warstwami aplikacji. Podstawową cegiełką budulcową aplikacji zgodnych z architekturą Spring są komponenty JavaBean. Jak się okazuje, przy niewielkim wsparciu ze strony kontenera Spring większość złożonej i zaawansowanej funkcjonalności może być osiągnięte przez wykorzystanie współpracujących ze sobą i komunikujących się komponentów JavaBean. Kolejny punkt ideologiczny architektury Spring dotyczy wykorzystania wyjątków. Autorzy wskazują, że większość wyjątków zgłaszanych przez komponenty aplikacji nie ma sensu poza kontekstem komponentu a mechanizm zgłaszania i przechwytywania wyjątków (gdzie w większości przypadków wyjątek jest tylko rejestrowany w dzienniku aplikacji) jest stanowczo nadużywany. Wreszcie, autorzy kładą bardzo silny nacisk na możliwość niezależnego, jednostkowego testowania modułów aplikacji. Część wyborów projektowych całej architektury jest podyktowana koniecznością zapewnienia wygodnego środowiska do testowania modułów w separacji od reszty aplikacji oraz chęcią zapewnienia środowiska do tworzenia aplikacji na podstawie testów, tzw. TDD (ang. test-driven development).
