Google Guice Framework for Dependency Injection heise Developer

Kutatás 2 336 843 Termékek

A Google Earth és a Maps példák a keresőmotor óriás innovatív szellemére. Más projektek bizonyították magukat a Google házon belüli fejlesztésében. Ennek a családnak egy fiatal tagja a nyílt forráskódú Guice keretrendszer, a Spring alternatívája.

A Google Guice, a Dependency Injection (DI) nyílt forráskódú keretrendszere az AdWords internetes hirdetési alkalmazás kibővítése során jött létre, és több száz fejlesztővel rendelkező projektekben a csapat méretezésével kapcsolatos problémák megoldására készült. Az elismert DI-keretrendszerek, például a népszerű tavasz [1] ellenére a Google saját, különösen könnyű változatot szeretett volna használni a belső szoftverfejlesztéshez (lásd "Laza kapcsolat").

A Java 5 generikus adatai és annotációi a keret lényeges részét képezik [2]. Ezenkívül a Guice támogatja a saját hatókörét (lásd a szójegyzéket), a szempont-orientált programozást (AOP) és a Spring integrációt. A statikus attribútumok injektálásának képessége, valamint a körös referenciák kezelése kiegészíti a képet.

A tervező a foglalási felületen keresztül éri el a HotelBooking és a MockBooking meghatározott osztályait (1. ábra).

Erre példa a szállodákat foglaló nyaralástervező alkalmazás (1. ábra). A tervező objektum (hívó) egy felületfoglalással foglalkozik, amely mögött konkrét megvalósítások (célobjektumok) vannak elrejtve. Annak érdekében, hogy a fejlesztés során ne kelljen folyamatosan lekérdeznünk a valós célrendszert, itt egy úgynevezett mock objektumot (dummy) használnak. A fejlesztőnek képesnek kell lennie arra, hogy könnyen áttérjen a produktív működésre.

A keretrendszernek különösen soványnak kell lennie, és jelentősen csökkentenie kell a "kazánlap kódját". Nehéz munka helyett a fejlesztőnek foglalkoznia kell az alapvető dolgokkal. Ebből a célból a Guice kizárólag a DI nagy teljesítményű megvalósítására koncentrál, és ennek megfelelően csökkentették, mind a JAR fájlok mérete, mind a memóriafelhasználás tekintetében. A Guice nem kezeli a központi XML fájlok függőségeit, hanem a Java kódban tárolja azokat.

konfliktusok megoldása

Konfliktusok megoldása a Java-val

A tapasztalatok azt mutatják, hogy a fejlesztés nem skálázódik, ha túl sok résztvevő versenyez az alapvető összetevőkhöz való hozzáférésért. A csúnya konfliktusok elkerülhetetlenek, ha megosztott XML fájlokkal dolgoznak. A Java fájlok szerkesztése szintén könnyebb és kevésbé hajlamos a hibákra, mint a nagy XML fájlok szerkesztése. Ez észrevehetően megkönnyíti az újrafeldolgozást és jobban támogatja az eszközöket. Guice már letette az AdWords gyakorlati tesztjét. Ez is része a jól ismert Struts 2 webkeretnek, amelyben a plug-in architektúra központi eleme. A Guice hasznos szolgáltatásokat nyújt az összes Java alkalmazásban. Különösen előnyösek a nagy projektek és azok, amelyek kizárólag a hatékony függőség-injektálásra összpontosítanak. Itt játszhatja ki a Guice az erősségeit, például a karcsúságot és az XML-mentes vezetékeket (lásd "Jól vezetékes").

A vakáció tervezésére szolgáló alkalmazást ismét példaként használjuk. Guice feladata, hogy a tervezőhöz hozzárendelje a kívánt konkrét foglalási objektumot, amelyhez a felületen keresztül férhet hozzá. A vizsgált esetben ennek a MockBooking objektumnak kell lennie. Ehhez tisztázni kell, hogy mit hova injekcióznak. A kérdés első részére egy úgynevezett "kötőanyaggal" rendelkező modul válaszol, amelyek együttesen hozzárendelik az interfészt a megvalósításhoz. A következő kódrészlet alkot ilyen modult, és a bind () metódussal köti a Booking felületet a konkrét MockBooking osztályhoz .

A tervező objektumban egy @Inject kommentár gondoskodik a "hol" -ról:

A @Inject kommentár azt jelzi, hogy a foglalás típusú objektumokat kell injektálni a konstruktor segítségével. A keret elsajátítja a konstruktor injektálását (mint a példában), valamint a módszert és a terepi injektálást. Ez azt jelenti, hogy a Guice bármilyen kommentált módszert is használhat, vagy közvetlenül beillesztheti őket egy attribútumba:

Az injektálható elemek olyan primitív típusok, mint az int vagy a char, valamint az enumok és általában bármely osztály példányai.

A teszt forgatókönyvet tovább lehet egyszerűsíteni úgy, hogy a PlanerModule és annak kötése nélkül elvégezzük, és megadunk egy alapértelmezett kötést a felületen a @ImplementedBy kommentár segítségével:

Miután a fejlesztő modellezte a függőségeket, Guice elkezdheti a munkát. Megkülönbözteti az inicializálást és a futási időt. Amikor az alkalmazás elindul, a rendszerindítás a gyökérobjektum injekciójával kezdődik. Guice gondoskodik a többiről úgy, hogy végigfut a függőségi grafikonon, és minden további injekciót rekurzív módon végez. Validálás történik, amely hiányosságokat vagy hibákat jelez. Használata olyan egyszerű, mint ebben a példában:

Minden kötés része egy olyan szolgáltató, amely a regisztrált osztály példányait biztosítja. Bizonyos esetekben hasznos vagy elkerülhetetlen, ha saját maga hoz létre objektumokat, és nem hagyja ezt a belső szabvány szolgáltatójának. Ha harmadik féltől származó könyvtárat használ, akkor például nem adhat meg @Inject kommentárokat. Egyedi szolgáltató segítségével továbbra is lehetséges a kötés. Az egyedi szolgáltatók lehetővé teszik a JNDI vagy a JMX útján szállított objektumokkal történő integrációt is.

Az injektor mint kulcselem

Ne féljen az injekcióktól

A Guice-struktúra legfontosabb eleme az injektor, amely kezeli a kötéseket (2. ábra). Ez utóbbiak az injekció célpontjánál kommentárokat használnak, és az injekció beadandó típusára utalnak. A szolgáltató létrehozza a típus példányait. A kötés hatóköre opcionális specifikáció, és ellenőrzi a generált és az injektált objektumok újrafelhasználását. Minden injekcióhoz Guice általában létrehoz egy új példányt a kérdéses tárgyról. Alternatív hatókörök: "Singleton", "Request" és "Session".

A leírt alapvető mechanizmusok mellett Guice számos további lehetőséget ismer. Ez magában foglalja a saját annotációinak meghatározását, amelyek például lehetővé teszik a repülési és bérelt autó foglalások további hozzárendelését.

Amikor hallja a függőség injektálását vagy a kontroll inverzióját, általában először Tavaszra gondol. Nem ok nélkül, mivel a tényleges szabvány mögött egy aktív közösség áll. Mint már említettük, létezése ellenére a Google szükségét látja saját megoldásának. Az olyan alternatívák, mint a JBoss Seam, az Apache HiveMind vagy a Pico-Container, nem akadályozták meg a vállalatot a házon belüli fejlesztésben.

Mindkét keret - a Spring és a Guice - a nyílt forráskódú termékekhez tartozik, és Apache 2.0 licenc alatt vannak. A Guice alkotóelemeként szereplő kommentárok és generikus elemek csak a Java 5-ből engedik használni. Ez nem vonatkozik a Springre, sőt a JDK 1.3-val is használható, és lényegesen több funkciót kínál, mint a Guice. Míg ez utóbbi a DI-re összpontosít, Spring is támogatja a tranzakciókat, a kitartást és saját web-keretrendszerrel rendelkezik. Alprojektek léteznek konfigurációhoz, biztonsághoz, kötegelt feladatokhoz és még néhányhoz.

Az objektumok közötti függőségek meghatározása képezi a DI keretrendszer gerincét. A függőségek tárolása és kiértékelése (az objektumok bekötése) jellegzetes jellemző. Ez egy másik jelentős különbséget mutat Spring és Guice között. A tavasz kifejezett megjelenítést és automatikus bekötést egyaránt lehetővé tesz. A Guice más megközelítést alkalmaz: Bár kifejezett reprezentációra támaszkodik, megkerüli a csevegő XML formátumot azáltal, hogy Java-kommentárok segítségével beépíti a kapcsolatokat a forráskódba. Ez az eljárás a részletes, de sok karbantartást igénylő, explicit ábrázolás és az automatikus bekötés keverékének tekinthető. A Spring lehetővé teszi függőségek létrehozását a Java kódban a JavaConfig programmal, de ez az alprojekt még mindig mérföldkő állapotban van.

teljesítmény

Kicsi, gyors, tiszta

A Guice megmutatja teljesítményének előnyeit a tavasszal szemben mind az alkalmazás indításakor, mind futás közben, amikor a kért objektumokat hozza létre. A Guice eléri a vezető szerepet, amikor objektumokat hoz létre a Java 5 párhuzamossági képességein keresztül. (Ennek azonban meg kell változnia a Spring 3-mal, amely teljes egészében a Java 5-re fog épülni.) Ezenkívül nem generálja azokat a proxyobjektumokat, amelyeket a Spring használ. Az, hogy ez mennyire releváns a gyakorlatban, az alkalmazás jellegétől függ.

Az eszköz kiválasztásakor a műszaki tulajdonságok és a funkciók köre mellett olyan szempontok is fontosak, mint a bonyolultság. A Google egyértelműen előnyben látja Guice-t az Spring-szel szemben az egyszerűség, az érthetőség, a karbantarthatóság, a megtanulhatóság és a teljesítmény szempontjából.

Összességében a két keret számos összehasonlítása izgalmat váltott ki az adott körökben. Végső soron azonban nem jön sem döntés, sem döntés, mivel bár mindkettő DI konténer, mégis más a hangsúlyuk: Guice kis „lábnyomot” hagy maga után, míg a Spring átfogó és erőteljes megoldásként kínálja magát. XML komplexitásának nagy része a DI-n kívüli funkciókból is származik. Mivel Guice nem fedi le ezeket a területeket, nincs igazi rivalizálás. Elképzelhető mindkét keret együttélése, mert Guice lehetővé teszi a tavaszi bab integrálását.

A Guice 2 terve - amelyet 2009 januárjára terveznek - számos fejlesztést tartalmaz, beleértve az építkezés meghallgatóját és az introspekciós API-t. A hallgatók belépési pontokat kínálnak objektumok létrehozásakor, hogy összekapcsolják saját logikájukat. Az API kiterjesztés célja az Injector objektum belsejének feltárása, és teljes hozzáférés biztosítása a függőségi grafikonhoz. Ez kiindulópontot jelentene például a vizualizációs eszközök számára. Az ütemterv olyan szolgáltatói módszereket is megnevez, amelyekkel a modulosztályok könnyebben megtervezhetők. Az egyéni szolgáltatók így rugalmasabb kötést hajthatnának végre, amely például csak egy bizonyos körben hatékony.

Következtetés

Egyetlen villanás sem a serpenyőben

A Guice még mindig új, ezért kevés produktív alkalmazás található a Google-on kívül. A fent említett Struts2 webkeret minden bizonnyal kivétel. A Google háttere és az AdWords használata azonban biztosítja, hogy a Guice ne kerüljön villanássá a serpenyőben. A már meglévő, harmadik féltől származó modulok ezt további jelzésként szolgálják. Ez magában foglalja azokat az összetevőket, amelyek lehetővé teszik a Guice számára a Hibernate vagy az Ajax framework DWR interakcióját.

Hátránya, hogy a projekt dokumentációja még mindig teljesen világos. Az egyre növekvő számú tapasztalati jelentés és utasítás némileg enyhíti ezt a hiányosságot. Építészeti szempontból azt is figyelembe kell venni, hogy a saját jegyzetek megnehezítik az osztályok újrafelhasználását a nem Guice projektekben. A Guice-t viszonylag könnyű megtanulni és bevezetése - még a meglévő projektekben is. További előny, hogy a keretrendszer lépésről lépésre telepíthető.

Tobias Lütticke
megoldás-építészként dolgozik az új-zélandi Wellington-i minisztériumban.

Christian Meder
a pforzheimi inovex GmbH vezető építésze.

szójegyzék

Kazánlap kódja: Ismétlődő, de szükséges séma F-kód, amely nem ábrázolja az üzleti logikát.

Injektor: Komponens, amely a kívánt objektum injektálásával teljesíti a függőséget.

Modul: Konténer konténerekhez, amelyek meghatározzák, hogy mit kell beadni.

Kötés: Kapcsolat az interfész és a megvalósítása között.

Hatály: Beadott tárgy terjedelme (pl. Kérés, munkamenet, szingulett).

(Egyedi) Szolgáltató: Létrehozza az injektálandó tárgyakat. Az "egyedi" változatban az alkalmazáson kívüli összetevők egyedi csatlakoztatásához.

Bootstrapping: A Guice inicializálása a gyökérobjektum injektálásával az automatikus vezeték bekapcsolása érdekében. Ezzel elkerülhető, hogy később minden egyes injekció esetében újra ki kell kérdeznie az injektort.

Kommentárok: Metainformációk, amelyeket a fejlesztő a Java osztályok forráskódjában tárol, megelőző "@" karakterrel.

Általános: Típusparaméterekkel paraméterezhető módszerek és osztályok.

Jól van bekötve

A vezetékezés leírja, hogy a keret hogyan kezeli az objektumok közötti függőségeket. Két alapvető forma létezik: a kifejezett reprezentáció XML-ben vagy Java-ban, és a keret futás közbeni automatikus értékelése (automatikus bekötés). Mindkét változat értékelhető. Auto bekötés esetén a keretrendszer megpróbálja felismerni az alkatrészek közötti kapcsolatokat. Az alkalmazás bonyolultságának növekedésével azonban problémát okoz: a teljesítmény egyre rosszabbá válik.

Laza kapcsolat

A Dependency Injection (DI) népszerű fogalom a szoftverfejlesztésben. Az elsődleges célok közül kettő: a szoftverek újrafelhasználhatóságának és karbantartásának egyszerűsítése az alkatrészek laza összekapcsolásával és a tesztelés megkönnyítésével.

Amikor egy A objektum hivatkozást tart egy B objektumra, általában ismeri annak megvalósítását. A DI koncepció előírja, hogy az A hívó és az általa megcélzott B célok közötti függőségek már nem tárolódnak A-ban. A B célobjektum melyik megvalósításával kell konkrétan foglalkozni, csak szükség esetén közöljük a hívóval. A konkrét B-vel való kapcsolatot erre a célra "injektálják" A-ba. Hívóként A nem ismeri a célobjektumot, amelyet a végső injekcióig használni kell.

A DI az Inversion of Control (IoC) paradigma, más néven hollywoodi elv: alkalmazása: Ne hívjon minket, hanem felhívunk. Ily módon a függőség-injektálás lehetővé teszi a különböző használati forgatókönyvek alkalmazását anélkül, hogy ehhez kellene igazítania a hívó forráskódját, például amikor a célobjektumok új megvalósításait adják hozzá. Az ilyen további célok általános példája egy szolgáltatás, mint az eredeti szolgáltatás tesztelési célú egyszerűsített változata. Ha a tényleges szolgáltatás sok erőforrást igényel és hosszú ideig fut, vagy egyáltalán csak a produktív környezetben érhető el, akkor a megvalósítás mint objektum (dummy) lehetővé teszi (gyorsabb) tesztelést.