Rámec Google Guice pre vývojárov závislých injekcií

Výskum v 2 336 843 Produkty

guice

Google Earth a Mapy sú príkladmi inovatívneho ducha giganta vyhľadávacieho nástroja. Pri internom vývoji spoločnosti Google sa osvedčili ďalšie projekty. Mladý člen tejto rodiny je open source framework Guice, štíhla alternatíva k Spring.

Google Guice, otvorený zdrojový rámec pre Dependency Injection (DI), bol vytvorený počas rozširovania aplikácie pre internetovú reklamu AdWords a mal vyriešiť problémy so škálovaním tímu, ktoré sa vyskytujú v projektoch s niekoľkými stovkami vývojárov. Napriek uznávaným DI rámcom, ako je populárny Spring [1], chcel Google pre svoj interný vývoj softvéru použiť svoj vlastný, obzvlášť ľahký variant (pozri „Voľný vzťah“).

Všeobecné a anotácie z Java 5 sú podstatnou súčasťou rámca [2]. Guice navyše podporuje svoje vlastné rozsahy (pozri slovníček), aspektovo orientované programovanie (AOP) a jarnú integráciu. Schopnosť vkladať statické atribúty, ako aj správa cyklických odkazov, to všetko dokresľujú.

Plánovač pristupuje k konkrétnym triedam HotelBooking a MockBooking cez rezervačné rozhranie (obr. 1).

Príkladom toho je aplikácia na plánovanie dovolenky, ktorá rezervuje hotely (obrázok 1). Objekt plánovača (volajúci) adresuje rezerváciu rozhrania, za ktorou sa skrývajú konkrétne implementácie (cieľové objekty). Aby ste počas vývoja nemuseli neustále dopytovať skutočný cieľový systém, používa sa tu takzvaný falošný objekt (atrapa). Vývojár by mal byť schopný ľahko prejsť na produktívnu prevádzku.

Rámec by sa mal javiť obzvlášť štíhly a výrazne znížiť „štandardný kód“. Namiesto tvrdej práce by sa mal vývojár zaoberať tým najnutnejším. Z tohto dôvodu sa spoločnosť Guice sústreďuje výlučne na vysoko výkonnú implementáciu DI a bola príslušne zoštíhlená, a to tak z hľadiska veľkosti súborov JAR, ako aj z hľadiska spotreby pamäte. Guice nespravuje závislosti v centrálnych súboroch XML, ale ukladá ich do kódu Java.

riešiť konflikty

Riešte konflikty s Javou

Skúsenosti ukazujú, že vývoj sa nemení, ak príliš veľa účastníkov súťaží o prístup k základným komponentom. Pri práci so zdieľanými súbormi XML sú škaredé konflikty nevyhnutné. Úpravy súborov Java sú tiež jednoduchšie a menej náchylné na chyby ako úpravy veľkých súborov XML. Vďaka tomu je refaktoring zreteľne ľahší a lepšie podporený nástrojmi. Spoločnosť Guice už absolvovala praktický test v službe AdWords. Je tiež súčasťou známeho webového rámca Struts 2, v ktorom je ústredným prvkom architektúry doplnku. Spoločnosť Guice môže vykonávať užitočné služby vo všetkých aplikáciách Java. Výhody majú najmä veľké projekty a tie, ktoré sa zameriavajú výlučne na efektívne vkladanie závislostí. Tu môže Guice predviesť svoje silné stránky, ako napríklad štíhlosť a zapojenie bez použitia XML (pozri „Dobre zapojené“).

Ako príklad sa opäť používa aplikácia na plánovanie dovolenky. Úlohou spoločnosti Guice je prideliť plánovačovi požadovaný konkrétny rezervačný objekt, ku ktorému má prístup cez rozhranie. V posudzovanom prípade by malo ísť o objekt MockBooking. Musí sa objasniť, do čoho sa kde vstrekuje. Na prvú časť otázky odpovedá takzvaný modul s „binderom“, ktorý spoločne priraďuje rozhranie k implementácii. Nasledujúci úryvok kódu tvorí taký modul a pomocou metódy bind () viaže rozhranie Booking na konkrétnu triedu MockBooking. .

Anotácia @Inject v objekte plánovača sa stará o miesto „kde“:

Anotácia @Inject naznačuje, že objekt typu Booking sa má vložiť pomocou konštruktora. Rámec ovláda injektor konštruktora (ako v príklade), ako aj vstrekovanie metód a polí. To znamená, že Guice môže tiež použiť akékoľvek anotované metódy alebo ich vložiť priamo do atribútu:

Injekčné prvky sú primitívne typy, ako napríklad int alebo char, ako aj enumy a vo všeobecnosti prípady akejkoľvek triedy.

Scenár testu je možné ďalej zjednodušiť tak, že sa zaobíde bez modulu PlanerModule s jeho väzbou a zadaním predvolenej väzby v rozhraní pomocou anotácie @ImplementedBy:

Keď vývojár modeluje závislosti, môže Guice začať pracovať. Rozlišuje medzi inicializáciou a runtime. Po spustení aplikácie sa bootstraping začína vložením koreňového objektu. Guice sa stará o zvyšok tým, že sa prepracuje cez graf závislostí a rekurzívne urobí všetky ďalšie injekcie. Prebieha overenie, ktoré naznačuje medzery alebo chyby. Jeho použitie je také jednoduché ako v tomto príklade:

Súčasťou každej väzby je poskytovateľ, ktorý poskytuje inštancie zaregistrovanej triedy. V určitých prípadoch môže byť užitočné alebo nevyhnutné vytvoriť si objekty sami a nenechať to na poskytovateľa interných štandardov. Ak používate knižnicu tretej strany, nemôžete tam napríklad vložiť anotáciu @Inject. S pomocou obyčajného poskytovateľa je stále možné vykonať väzbu. Vlastní poskytovatelia tiež umožňujú integráciu s objektmi doručovanými prostredníctvom JNDI alebo JMX.

Injektor ako kľúčový prvok

Nebojte sa injekcií

Kľúčovým prvkom v štruktúre Guice je injektor, ktorý spravuje väzby (obrázok 2). Posledné menované používajú anotáciu na cieľovej injekcii a označujú typ, ktorý sa má injektovať. Poskytovateľ vytvára inštancie typu. Rozsah väzby je voliteľnou špecifikáciou a riadi opätovné použitie vygenerovaných a vložených objektov. Pre každú injekciu Guice zvyčajne vytvorí novú inštanciu predmetného objektu. Alternatívne rozsahy sú „Singleton“, „Žiadosť“ a „Relácia“.

Okrem opísaných základných mechanizmov Guice pozná množstvo ďalších možností. Patrí sem definícia vlastných anotácií, ktoré napríklad umožňujú ďalšie priradenie rezervácií letov a prenájmov automobilov.

Keď počujete Vstrekovanie závislostí alebo Prevrátenie kontroly, zvyčajne sa vám najskôr vybaví Jar. Nie bez dobrého dôvodu, pretože to je de facto štandard, ktorý má za sebou aktívnu komunitu. Ako už bolo spomenuté, Google napriek svojej existencii vidí potrebu vlastného riešenia. Alternatívy ako JBoss Seam, Apache HiveMind alebo Pico-Container nezabránili spoločnosti vo vývoji vo vlastnej réžii.

Oba rámce - Spring a Guice - patria k produktom open source a sú pod licenciou Apache 2.0. Anotácie a všeobecné informácie ako súčasti Guice umožňujú použitie iba z Javy 5. Toto sa nevzťahuje na Spring, dá sa dokonca použiť s JDK 1.3 a ponúka podstatne viac funkcií ako Guice. Zatiaľ čo druhý sa zameriava na DI, Spring podporuje aj transakcie, vytrvalosť a má svoj vlastný webový rámec. Existujú podprojekty týkajúce sa konfigurácie, zabezpečenia, dávkových úloh a niekoľkých ďalších.

Definícia závislostí medzi objektmi tvorí chrbticu rámca DI. Charakteristickým znakom je spôsob ukladania a vyhodnocovania závislostí (zapojenie objektov). To ukazuje ďalší zásadný rozdiel medzi Spring a Guice. Pružina umožňuje explicitné zobrazenie aj automatické zapojenie. Guice má iný prístup: Aj keď sa spolieha na explicitné znázornenie, obchádza chatrný formát XML začlenením vzťahov do zdrojového kódu pomocou anotácií Java. Tento postup možno chápať ako zmes medzi podrobným, ale na údržbu náročným, explicitným znázornením a automatickým zapojením. Jar tiež umožňuje vytváranie závislostí v kóde Java pomocou JavaConfig, ale tento podprojekt je stále v stave míľnika.

výkon

Malý, rýchly, prehľadný

Guice ukazuje svoje výkonnostné výhody oproti Springu pri spustení aplikácie aj za behu, pokiaľ ide o vytváranie požadovaných objektov. Spoločnosť Guice dosahuje prvenstvo pri vytváraní objektov prostredníctvom schopností súbežnosti Java 5. (To by sa malo zmeniť s jarom 3, ktorý bude úplne založený na Jave 5.) Okrem toho negeneruje objekty proxy, ktoré Spring používa. Nakoľko je to v praxi relevantné, závisí to od povahy žiadosti.

Pri výbere nástroja sú okrem technických vlastností a rozsahu funkcií dôležité aj aspekty, ako je zložitosť. Google vidí v Guice jednoznačne výhodu oproti Spring, čo sa týka jednoduchosti, prehľadnosti, udržiavateľnosti, učiteľnosti a výkonu.

Celkovo možno povedať, že početné porovnania týchto dvoch rámcov vyvolali vzrušenie v príslušných kruhoch. V konečnom dôsledku však neprichádza k rozhodnutiu buď - alebo, pretože hoci sú oba kontajnery DI, majú odlišné zameranie: Guice zanecháva malú „stopu“, zatiaľ čo Spring sa ponúka ako komplexné a výkonné riešenie. Veľa z jeho zložitosti XML vyplýva aj z funkcií mimo DI. Keďže Guice nepokrýva tieto oblasti, neexistuje skutočná rivalita. Je možné si predstaviť koexistenciu oboch rámcov, pretože Guice umožňuje integráciu Spring Beans.

Plán pre Guice 2 - plánovaný na január 2009 - obsahuje množstvo vylepšení vrátane poslucháčov stavieb a introspekčného API. Poslucháči ponúkajú vstupné body pri vytváraní objektov, ktoré nadväzujú na vašu vlastnú logiku. Rozšírenie API je určené na odhalenie vnútorných častí objektu Injector a umožnenie úplného prístupu k grafu závislostí. To by poskytlo východiskový bod napríklad pre vizualizačné nástroje. V pláne sú tiež pomenované metódy poskytovateľov, pomocou ktorých možno ľahšie navrhnúť triedy modulov. Zákaznícki poskytovatelia by tak mohli vykonávať pružnejšiu väzbu, ktorá je účinná napríklad iba v určitom rozsahu.

Záver

Ani záblesk na panvici

Guice je stále nový, takže mimo Google existuje len málo produktívnych aplikácií. Spomínaný webový rámec Struts2 je určite výnimkou. Pozadie Google a používanie služby AdWords však zabezpečia, aby Guice neskončil ako blesk v panve. Ďalším znakom toho sú teraz existujúce moduly tretích strán. Patria sem komponenty, ktoré umožňujú spoločnosti Guice komunikovať s režimom dlhodobého spánku alebo s rámcom Ajax DWR.

Negatívom je, že projektová dokumentácia je stále celkom jasná. Zvyšujúci sa počet správ a pokynov o skúsenostiach tento nedostatok trochu zmierňuje. Z architektonického hľadiska by sa malo tiež vziať do úvahy, že vlastnícke anotácie sťažujú opätovné použitie tried v projektoch iných ako Guice. Guice je pomerne ľahké sa naučiť a predstaviť ju - dokonca aj v existujúcich projektoch. Ďalšou výhodou je, že rámec je možné inštalovať krok za krokom.

Tobias Lütticke
pracuje ako architekt riešenia na ministerstve vo Wellingtone na Novom Zélande.

Christian Meder
je hlavným architektom v spoločnosti inovex GmbH v Pforzheimu.

glosár

glosár

Kód varného štítku: Opakovaný, ale požadovaný F-kód schémy, ktorý neznázorňuje obchodnú logiku.

Injektor: Komponent, ktorý spĺňa závislosť vstreknutím požadovaného objektu.

Modul: Kontajner na väzby, ktorý definuje, čo sa má vstreknúť.

Viazanie: Prepojenie medzi rozhraním a jeho implementáciou.

Rozsah: Rozsah vloženého objektu (napr. Požiadavka, relácia, singleton).

(Vlastný) poskytovateľ: Vytvára objekty, ktoré sa majú vstreknúť. Vo variante „Custom“ pre individuálne pripojenie neaplikačných komponentov.

Bootstrapping: Inicializácia Guice vstreknutím koreňového objektu za účelom spustenia automatického zapojenia. Takto sa vyhnete nutnosti opätovného interogovania injektora pri každej injekcii.

Anotácie: Meta informácie, ktoré vývojár ukladá do zdrojového kódu tried Java s predchádzajúcim znakom „@“.

Generiká: Metódy a triedy, ktoré možno parametrizovať parametrami typu.

Dobre zapojený

Dobre zapojený

Zapojenie popisuje spôsob, akým rámec riadi závislosti medzi objektmi. Existujú dve základné formy: explicitná reprezentácia v XML alebo Java a automatické vyhodnotenie rámcom za behu (automatické zapojenie). Je možné vyhodnotiť obidva varianty. V prípade automatického zapojenia sa rámec snaží pochopiť vzťahy medzi samotnými komponentmi. S narastajúcou zložitosťou aplikácie to však vytvára problém: výkon sa zhoršuje a zhoršuje.

Voľný vzťah

Voľný vzťah

Dependency Injection (DI) je populárny koncept vo vývoji softvéru. Dva z hlavných cieľov: zjednodušiť opätovnú použiteľnosť a údržbu softvéru voľným prepojením komponentov a uľahčiť testovanie.

Keď má objekt A odkaz na objekt B, obvykle pozná svoju implementáciu. Koncept DI poskytuje, že závislosti medzi volajúcim A a cieľmi B, ktoré oslovil, sa už v A. neukladajú. Volajúci je iba v prípade potreby informovaný, ktorej implementácii cieľového objektu B sa má konkrétne venovať. Vzťah ku konkrétnemu B sa na tento účel „vstrekuje“ do A. Ako volajúci A nepozná cieľový objekt, ktorý sa má použiť, až do poslednej injekcie.

DI je aplikácia paradigmy inverzie kontroly (IoC), známej tiež ako hollywoodsky princíp: Nevolajte nám, zavoláme vám. Týmto spôsobom umožňuje vkladanie závislostí použiť rôzne scenáre použitia bez toho, aby ste museli upravovať zdrojový kód volajúceho, napríklad keď sú pridané nové implementácie cieľových objektov. Bežným príkladom takéhoto ďalšieho cieľa je služba ako zjednodušený variant pôvodnej služby na testovacie účely. Ak skutočná služba potrebuje veľa zdrojov a beží dlho, alebo je k dispozícii iba v produktívnom prostredí, implementácia ako falošný objekt (atrapa) umožňuje (rýchlejšie) testovanie.