Jednou z charakteristických vlastností aplikačního rámce Spring™ je snaha neomezovat žádným způsobem architekta aplikace, nevnucovat jeho třídám závislost na třídách rámce, snaha o maximální transparentnost rámce. Třídy aplikace by při správném návrhu neměly o rámci vůbec „vědět“ a měla by tak existovat možnost zaměnit rámec Spring™ za jiné prostředí, řekněme EJB, dojde-li například ke změně obchodních požadavků na aplikaci. Z tohoto důvodu neexistuje striktní návod návrhu Spring™ aplikací, ovšem Rod Johnson již v [1] v kapitole 3 definoval aplikační architekturu s názvem Architektura odlehčených kontejnerů (Lightweight Container Architecture), které se komunita vývojářů při návrhu Spring aplikací více méně drží.

Ve [2] je uvedená architektura zachycena pomocí schématu 1.1 – „Schéma typické architektury Spring aplikace“.

Na obrázku můžeme vidět, že základem architektury je typická třívrstvá architektura, skládající se z prezentační, aplikační a perzistenční vrstvy. Infrastrukturní třídy rámce pak poskytují podporu všem těmto vrstvám. Vzhledem k integraci mnoha existujících specializovaných aplikačních rámců, které se koncentrují na konkrétní části tohoto modelu, lze pro webovou prezentační vrstvu použít jak Spring™ MVC modul, tak i rámce Struts™ či Webwork™. Pro perzistenci objektů do databáze pak lze použít jak abstrakční JDBC vrstvy rámce Spring™, tak populární ORM nástroje, jakými jsou Hibernate™ či JDO.

Na základě ohlasů odborníků, bloggerů i vývojářů, kteří sdělují své názory na komunitních fórech a v mailových konferencích, lze usuzovat, že nejrozšířenější kombinací technologií při vytváření webových aplikací spravovaných rámcem Spring™ je kombinace Spring™ MVC (pro správu prezentační webové vrstvy) a Hibernate™ (perzistenční vrstva). Z toho také vycházíme při návrhu vzorové aplikace, která je obsahem přílohy A (???) této práce. Taková webová aplikace tedy sleduje následující přibližný tok zpracování požadavku uživatele.

Spring MVC modul předává požadavek určitému kontroleru z vrstvy kontrolerů. Tyto kontrolery by měly být navrženy tak, aby neobsahovaly žádnou aplikační logiku a aby pouze zpracovávaly vstupy z webového uživatelského rozhraní a připravovaly výstupy pro toto rozhraní. Samotnou aplikační logiku by měly vykonávat jednotlivé objekty z aplikační vrstvy (také označované jako manažeři {managers} či servisní objekty {services}). Jednotlivé kontrolery tedy volají metody manažerů a předávají jim (či od nich získávají) doménové objekty. Získané objekty pak předávají šablonám prezentační technologie, typicky JSP, která má na starost vygenerování příslušného HTML kódu.

Případná vrstva webových služeb pak volá tytéž metody aplikační vrstvy jako webová vrstva. Tak dochází k rychlému a přehlednému znovupoužití kódu aplikační vrstvy.

Samy objekty aplikační vrstvy mají na starost veškeré výpočty nezávislé na prezentační vrstvě. Předávají doménové objekty perzistenční vrstvě a tyto objekty od ní také získávají. Pro každou konkrétní třídu servisního objektu pak existuje odpovídající rozhraní, čímž je vyhověno základnímu požadavku OO návrhu, tedy požadavku tzv. programování do rozhraní.

Perzistenční vrstva v typické Spring™ aplikaci využívá návrhového vzoru Objekt přistupující k datům (DAO - Data Access Object), tzn. že v aplikační vrstvě se nenachází žádný kód pro manipulaci s konkrétním úložištěm dat (databází, LDAP atd.), takový kód je součástí perzistenční vrstvy. Ke každé třídě perzistenční vrstvy také existuje odpovídající rozhraní.

Jednotlivé vrstvy používají pouze rozhraní vrstvy nižší, tedy prezentační třídy využívají metod rozhraní aplikační vrstvy, servisní objekty pak volají metody perzistenčních tříd. Programování do rozhraní pak umožňuje snadné nahrazení konkrétních tříd, které daná rozhraní implementují. To se týká všech vrstev. Lze vyměnit konkrétní implementace kontrolerů, servisních objektů i DAO objektů. Zejména v případě DAO objektů je pak snadné vyměnit například klasickou JDBC implementaci za řekněme Hibernate™ implementaci, což může být poměrně častý požadavek při současném rychlém růstu popularity ORM nástrojů.

V běžné webové aplikaci jsou objekty všech tří vrstev většinou bezstavové, čili je vhodné implementovat kontrolery, servisní objekty i DAO objekty pomocí návrhového vzoru Jedináček (Singleton). K inicializaci všech těchto jedináčků a jejich vzájemnému provázání je pak rámcem Spring využit DI.

Jakou konkrétní podporu všem vrstvám popsané architektury Spring™ poskytuje si ukážeme v následujících kapitolách této práce.