SPRING FRAMEWORK bemutatása Vasi Sándor Greencode Kft Sandor.vasi@greencode.hu

A Spring Framework alapelvei A J2EE fejlesztésének nem kellene ilyen bonyolultnak lennie (Rod Johnson – J2EE Development without J2EE) Legyen a keretrendszer lightweight Rod Johnson – egy tapasztalt J2EE architect írt egy könyvet arról, hogy mi a rossz a J2ee-ben, majd ezekből a kritikákból fakadóan megalkotta a Spring Framework-öt. (2003 körül)

A Spring Framework alapelvei 2. Az OOP irányelvek sokkal fontosabbak, mint a bármelyik framework, mint pl a J2EE Túl sok a Checked Exception a Java-ban. A framework ne kényszerítsen a használatára A tesztelhetőséget elő kell segítenie egy framework-nek Fejlesztési ciklus javítása == produktuvitás növelése Ha megnézzük a J2EE-t, hogy mit csinál? Szeparálja a működést az adatoktól. Ez tökéletesen szembemegy az OO irányelvekkel. Az EntityBean-ek elszeparálódnak a DTO-któl azaz a Data Transfer Object-ektől. A J2EE-nek nem lenne szabad, hogy rákényszerítsen minket egy régi, rossz design-ra. Sokkal fontosabbak az OOP alapelvek, mint, hogy legyen egy frankó J2EE szerverünk. Egy jobban megdizájnolt alkalmazást sokkal könnyebb elfuttatni egy lightweight szervletkonténeren is. Ha nincs DB connection, akkor úgy sem lehet mit csinálni, az egy kritikus hiba, nincs értelme a fejlesztőt egy try-catch ág kiírására kényszeríteni, az alkalmazás menthetetlen. Az EJB-nél egy kissé körülményes a tesztelhetőség, mert le kell buildelni az alkalmazást, be kell tenni egy EJB konténerbe, és úgy lehet futtatni a tesztet. Ez körülmlényes. Fordítás – fordított kód konténerbe juttatása – tesztelési ciklus rövid, ezért növelhető a produktivitás. Egy EJB konténer 2-3 perc, amég elindul. Ez nem OKÉS.

Konténerek A konténerek szerződések. A kód, amiket írunk, és a konténerekbe helyezünk, másként működnek, mintha a konténeren kívül futtatjuk őket. Vegyük a szervlet konténert. Ki kell terjeszteni a javax.servlet interfészt, és ha egy ilyen kódot a web container-be teszünk, akkor az szervletként funkcionál. A J2EE konténerekben található ilyen, és ehhez hasonló “szerződések” relatíve szigorúak. Nagyon sok a megkötés bennük. Egy Spring konténerben az ilyen szintű szabályozások eléggé lazák. Kb annyi, hogy írj Java Bean-eket, és majd azokkal a Spring elboldogul. A SPRING-es konténer egyértelműen könnyedebb, mint egy J2EE konténer.

Mi szükséges a SPRING működéséhez? Egy külső alkalmazás, ami inicializálja a SPRING-et. (Ez lehet akár a web-container is) Osztályok, amelyek BEAN-ek, amikhet majd el tudok érni a framework segítségével Bean Factory vagy Application Context Konfigurációs fájl XML annotáció Java osztály Spring lib-ek

Spring Framework Dependency Injection Aspect-Oriented Programming including Spring's declarative transaction management Spring MVC web application and RESTful web service framework Foundational support for JDBC, JPA, JMS és még sok egyéb…

other class Dependency Injection class Dependency Injection Mit jelent a “dependency” – azaz függőség? Mit jelent a dependency Injection? Szószerint lefordítva: függőség beszúrása. Kezdjük azzal, hogy mi az, hogy függőség? A dependency nem más, mint egy másik objektum, aminek az egyik funkciójára az osztályodnak szüksége van. DEPENDENCY uses class other class

Dependency Injection 2. A dependency injection segítségével: MODEL DATABASE FETCH PUSH Tehát, ha van egy model objektumod, amely adatokat szed egy adatbázis objektumtól, akkor azt mondhatjuk, hogy a modell osztályunknak van egy függősége, mégpedig a database objektum. Most, hogy már tudjuk, hogy mi az a függőség, azaz, dependency, beszéljünk arról, mit jelent egy függőséget injektálni. Függőséget beinjektálni annyi jelent, hogy a függőség be van “push”-solva, be van hozva az osztályunkba kívülről. Kívülről alatt azt kell érteni, hogy nem a model osztályomban inicializálom a külső objektumot new operátor segítségével, hanem ehelyett Egy már kész függőség objektumot kapok bemeneti paraméter, vagy egy setter változó révén. Ennyi az egész dependency injection. Semmi másról nincsen szó. A dependency injection segítségével: nem kell többé metódusainkban a new operátort használni helyette megkapjuk azt paraméterként

Miért jó ez nekünk? Dependency injection 3. public void myMethod(DataBase db) { db.fetchData … } De miért szükséges nekünk, hogy a függőségeket kívülről injektáljuk be? Miért jó ez nekünk?

Dependency Injection 4. Házépítő robot A robot deszkákból falakat tud össze- építeni. Mit tegyünk, amikor arra kerül a sor, hogy az ajtót kell beépíteni? Felprogramozzuk a robotunknat, hogy tudjon egyedi ajtót is építeni a deszkákból? vagy Ajtógyártók szabvány ajtóit építtetjük be vele? A legrugalmasabb megoldás természetesen az, ha szabvány ajtót éppíttetünk be egy harmadik féltől. decoupeling

Dependency Injection 5. A Dependency Injection függetleníti a modeljeinket a külsú függőségektől (dependency) Ezt a műveletet az angol szakirodalom decoupeling –nek nevezi Miért fontos a modellek függetlenítése egymástól?

Dependency Inversion Principal Magasszintű moduloknak nem szabad alacsony szintű moduloktól függniük. Midnkét modulnak absztakcióktól kell függnijük. Az absztrakcióknak nem szabad a részletekktől függniük, pont ellenkezőleg, a részleteknek kell az absztakcióktól függniük.

Dependency Inversion Principle 2. CLASS Dependency Dependency Implements Dependency Interface Az interfészek segítségével az implementációkat függetleníthetjük egymástól. Tetszőleges implementációt megvalósíthatunk és alkamazhatunk a rendszerünkben, mindaddíg, amíg azok az interface-ban “vállaltakat” teljesítik. A Dependency Injection segítségével a kódunkat függetleníthetjük az alacsonyabb szintű moduloktól. Dependency 2 Soft Dependency

Dependency Inversion Principal 3. A Dependency Injection használatával a kódunk: Tisztálbb lesz Könnyebb lesz módosítani és könnyebb lesz újrafelhasználni

Hogyan inicializáljuk a függőségeket? Osztályaink most már külső dependency-ktől függnek Hogy derítjük ki, hogy a függőségeknek vannak-e más függőségeik? Hogyan inicializáljuk a külső függőségeket? Most, hogy a Dependency Injection-t már adaptáltuk, egy újabb prolémával szembesülünk.

Service Locator Design Pattern Adott objektum (szolgáltatás) létrehozását kiveszi a szolgáltatás igénylője (kliens) hatásköréből. A szolgáltatást a komponens konténer hozza létre és tárolja (registry), a kliens a konténer API-n keresztül érheti el az arra mutató referenciát (lookup). Egyéb elnevezései:Object Factory, Component Broker, Component Registry

Service Locator működése Minden esetben, amikor meghívjuk a getDependency() metódusunkat, Inicializál, vagy meglévő objektumot hoz létre A Service Locator nagy előnye, hogy komplex függőségeket is transzparensen fel tud oldani A Service Locator megnéz egy általa nyilvántartott repozitory-ban, hogy a keresett függőség már létezik-e. Ha igen, akkor azt használja, ha nem, akkor létrehozza, eltárolja, majd azt adja vissza.

SPRING – DI példa class Traveller { public static void main(String[] args) { Car car = new Car(); car.move(); } class Car { public void move() { System.out.println(“move”); Mint látható, new operátort használtunk a kocsi létrehozásához. Ha bevezetünk később egy repülő, vagy motor osztályokat, és lecseréljük a kocsit, változtatni kell a referencia, és a new operátor mindkét oldalán.

SPRING – DI példa class Traveller { public static void main(String[] args) { Vehicle v = new Car(); v.move(); } class Car implements Vehicle { @Override public void move() { System.out.println(“move”); interface Vehicle { void move(); } Fejlesztünk egy kicsit a kódon, bevezetünk egy interfész-t … Az operátor bal oldalán már megszabadultunk a konkrét osztálytól, de a new operátor másik odlalán még mindig kell egy konkrét osztályt megadni. Ettől nem tudunk megszabadulni.

SPRING – DI példa class Traveller { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); Vehicle v = context.getBean(“vehicle”); v.move(); } @Component class Car implements Vehicle { @Override public void move() { System.out.println(“move”); interface Vehicle { void move(); } Fejlesztünk egy kicsit a kódon, bevezetünk egy interfész-t … Az operátor bal oldalán már megszabadultunk a konkrét osztálytól, de a new operátor másik odlalán még mindig kell egy konkrét osztályt megadni. Ettől nem tudunk megszabadulni.

SPRING – DI példa Spring framework-kel CAR WHEEL A Car igényelni fog egy Wheel objektumot Fejlesztünk egy kicsit a kódon, bevezetünk egy interfész-t … Az operátor bal oldalán már megszabadultunk a konkrét osztálytól, de a new operátor másik odlalán még mindig kell egy konkrét osztályt megadni. Ettől nem tudunk megszabadulni. Spring framework-kel CAR WHEEL A Car kap majd egy Wheel objektumot a konténertől

SPRING tesztelése @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration("classpath:spring-config.xml") public class SpringAppTests { @Autowired private HelloService helloService; @Test public void testSayHello() { Assert.assertEquals("Hello world!", helloService.sayHello()); }

MAVEN http://maven.apache.org Build mechanizmus egyszerűsítésére jött létre Külső library-k kezelése (Nincs többé lib verziózás, lib-ek másolgatása) Maven Repository Maven életciklus: clean, compile, deploy, install, … Packaging types: ear, ejb, jar, war, …

Köszönöm a figyelmet!