Je jaro, tedy čas nadmíru vhodný k zamyšlení se nad Springem. Předem bych chtěl upozornit, že jsem jeho velký fanoušek, takže se ode mě asi velké kritiky nedočkáte. Také nečekejte žádný technický návod něco podobného. Bude to prostě jen takové zamyšlení proč je ten Spring tolik populární.
Při programování člověk často naráží na problémy, u kterých si říká: „Tohle už musí být stokrát vyřešeno, proč to musím řešit znovu?“. Tomuto druhu problémů se dá čelit dvěma způsoby. Buď se porozhlédnout po internetu jestli neexistuje nějaké řešení nebo problém řešit po svém. První přístup má nevýhodu v tom, že existuje několik produktů na řešení našeho problému, my si mezi nimi musíme vybrat a potom se daný produkt naučit. Na druhou stranu obvykle dostaneme řešení, které funguje bez větší pracnosti. Druhý přístup přinese požitek ze zajímavé práce, ale přináší nebezpečí, že místo abychom programovali to co máme, tak programujeme podpůrnou knihovnu. Navíc platí známá poučka, že v kódu který nenapíšeme chybu neuděláme.
Spring slouží k zjednodušení prvního přístupu. Zjednodušuje nám často řešené problémy a usnadňuje použití existujících knihoven. Pokud se například rozhodneme používat JDBC, můžeme samozřejmě použít JDBC API přímo. Nejen že musíme zdlouhavě neustále dokola psát TCFTC bloky, ale navíc riskujeme, že někde zapomeneme zavřít připojení atp. (Rod Johnson se vyjádřil o tom, že když někdo používá JDBC tak se jedná o „Sackable offence“ – důvod k vyhazovu.) Při přímém použití JDBC také není vůbec triviální správa transakcí přesahujících jednu metodu. Když se rozhodnu použít Spring, nejen že se mi výrazně zjednoduší kód, ale také dostanu přístup k spoustě bonusů jako je třeba právě snadná správa transakcí nebo překlad SQL vyjímek na srozumitelné. Proto také, když se mě někdo zeptá co to je ten Spring tak nezačnu mluvit o IoC, ale předvedu jak snadno se dá používat JDBC.
Spring samozřejmě není jen o JDBC, ale řeší spoustu jiných stále se opakujících problémů. Jako jeden z nich mohu uvést bezpečnost. To je problém, který se řeší znovu a znovu. Jak v JEE aplikaci zajistit autentifikaci a autorizaci? Spring nám přináší projekt ACEGI, který využívá stávající produkty a standardy a propojuje je v snadno použitelný celek. To je jeden z dalších aspektů Springu. Pokud již existuje řešení, neimplementuje ho znovu, jen poskytne cestu jak ho snadněji využít. (snad jen s vyjímkou MVC frameworku 🙂
Podobných příkladů se dá uvést hodně, takže jen krátce. Na Spring se obrátím když chci snadno používat Hibernate, využívat AOP, načítat lokalizační balíčky, konfigurovat aplikaci, vzdáleně volat metody, používat deklarativní transakce nebo volat a implementovat EJB.
U toho posledního bych se chvilku zdržel. Vztah mezi EJB a Springem je zvláštní, jejich pole působnosti se překrývá. Oba produkty umí deklarativní transakce, objektově relační mapování, bezpečnost a EJB ve verzi 3 vypadají dokonce i jako snadno použitelně. Mám podezření, že se někteří mí kolegové těší, že až se jednou EJB 3 začnou používat, tak Spring skončí. Já jejich názor nesdílím. Záběr Springu je mnohem větší než EJB a jsou funkce, které EJB nebo obecně JEE nikdy nebudou poskytovat. Ne proto, že by byly špatné, ale asi nemůžeme od standardu chtít, aby nám poskytoval funkce pro snazší použití open source produktů.
EJB mají samozřejmě výhodu v tom, že jde o standard. To je ale i jejich nevýhoda. Než se standardizační skupina dohodne na tom jak bude vypadat další verze a ta se následně dostane do produkce, uběhne obvykle několik let. Mezitím už je už technologická špička někde jinde. Dovolil bych si tvrdit, že nebýt Springu a Hibernate tak by EJB 3 specifikace vypadala úplně jinak a u SUNu by mysleli, že POJO je mexický zpěvák.
Nedíval bych se ale na Spring a EJB jako na soupeře i když při pohledu na tábory jejich příznivců to tak vypadá. Ani autoři Springu netvrdí, že EJB jsou k ničemu. Pro větší aplikace nasazené v clusteru mají své opodstatnění. Spring proto i obsahuje třídy zjednodušující implementaci EJB 2.1. Uvidíme jak se situace bude vyvíjet po tom, co se EJB 3 dostanou do produkce.
Co říci závěrem? Snad jen to, že až příště budete řešit problém, o kterém si říkáte že už musí být stokrát vyřešený, až budete pracovat s komplikovaným low level API, zkuste se podívat do dokumentace Springu, třeba tam najdete řešení.