Intro Inverzió, az Ellenőrzés Függőség Injekció a Tavaszi

Áttekintés

ebben A cikkben bemutatjuk, hogy a fogalmak, a nemzetközi olimpiai bizottság (Inversion of Control), DI (Dependency Injection), majd akkor nézd meg, hogy ezek végre a Tavaszi keret.,

mi a vezérlés inverziója?,

a vezérlés inverziója a szoftverfejlesztés egyik alapelve, amellyel a program objektumainak vagy részeinek vezérlése egy tartályba vagy keretrendszerbe kerül. Leggyakrabban objektumorientált programozás keretében használják.

ezzel szemben a hagyományos programozási, amelyben az egyéni kód teszi a hívások egy könyvtár, Nob lehetővé teszi, hogy egy keret, hogy átvegye az irányítást az áramlás a program felhívja a egyedi kód. Ennek engedélyezéséhez a keretrendszerek absztrakciókat használnak további beépített viselkedéssel., Ha saját viselkedésünket szeretnénk hozzáadni, akkor ki kell terjesztenünk a keretrendszer osztályait, vagy bővítenünk kell saját osztályainkat.,

Az előnye ennek építészet:

• függetlenítés egy-egy feladat végrehajtása a végrehajtás
• így könnyebb váltani a különböző implementációk
• nagyobb modularitás egy program
• nagyobb könnyű a vizsgálati program elkülönítésével egy alkatrész, vagy gúnyolódik a függőségek, valamint lehetővé teszi a komponensek kommunikálni szerződések

Inverzió az Ellenőrzés lehet elérni különböző mechanizmusok, mint például: Stratégia tervezési minta, Service Locator minta, Gyári minta, valamint a Függőség Injekció (DI).,

a következő di-t fogjuk megnézni.

mi a Dependency Injection?

a függőségi befecskendezés egy olyan minta, amelyen keresztül a NOB végrehajtható, ahol az invertált vezérlés az objektum függőségeinek beállítása.

az objektumok más tárgyakkal való összekapcsolásának vagy az objektumok más tárgyakba történő “befecskendezésének” cselekedetét egy Összeszerelő végzi, nem pedig maguk a tárgyak.,

így hozhat létre objektumfüggőséget a hagyományos programozásban:

public class Store { private Item item; public Store() { item = new ItemImpl1(); }}

a fenti példában be kell állítanunk az elem interfész végrehajtását az Áruházosztályon belül.

a DI használatával átírhatjuk a példát anélkül, hogy megadnánk a kívánt elem végrehajtását:

public class Store { private Item item; public Store(Item item) { this.item = item; }}

a következő szakaszokban meglátjuk, hogyan tudjuk biztosítani az elem végrehajtását metaadatokon keresztül.,

mind a NOB, mind a DI egyszerű fogalmak, de mély következményekkel járnak a rendszereink felépítésében,ezért érdemes megérteni őket.

A tavaszi Nob konténer

a NOB konténer a NOB-t megvalósító keretrendszerek közös jellemzője.

a tavaszi keretrendszerben a NOB tárolót az Interface ApplicationContext képviseli. A rugós konténer felelős a babnak nevezett objektumok telepítéséért, konfigurálásáért és összeszereléséért, valamint életciklusuk menedzseléséért.,

A Spring framework az ApplicationContext interface — ClassPathXmlApplicationContext and FileSystemXmlApplicationContext for standalone applications, and WebApplicationContext for web applications.

a bab összeállításához a tároló konfigurációs metaadatokat használ, amelyek XML konfiguráció vagy megjegyzések formájában lehetnek.

itt van egy módja annak, hogy manuálisan instantiate konténer:

ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

az elem attribútum a fenti példában, tudjuk használni metaadatok., Ezután a tároló elolvassa ezt a metaadatot, majd felhasználja a bab összeszerelésére futásidőben.

a függőségi befecskendezés tavasszal kivitelezőkön, beállítókon vagy mezőkön keresztül történhet.

konstruktor-alapú függőségi befecskendezés

konstruktor-alapú függőségi befecskendezés esetén a tartály egy konstruktort hív meg argumentumokkal, amelyek mindegyike egy olyan függőséget képvisel, amelyet beállítani akarunk.

A Spring minden egyes argumentumot elsősorban típus szerint határoz meg, majd az Attribútum neve és a disambiguation indexe következik., Nézzük meg a bean konfigurációját és annak függőségeit kommentárokkal:

a @konfigurációs megjegyzés azt jelzi, hogy az osztály A bean definíciók forrása. Azt is hozzá tudjuk adni több konfigurációs osztályhoz.

A @ Bean annotáció egy bab definiálására szolgáló módszernél használatos. Ha nem adunk meg egyéni nevet,akkor a bean név alapértelmezés szerint a módszer neve.

Az alapértelmezett singleton hatókörrel rendelkező bab esetében a Spring először ellenőrzi, hogy létezik-e már a bean gyorsítótárazott példánya, és csak akkor hoz létre újat, ha nem., Ha a prototípus hatókört használjuk, a tároló minden metódushíváshoz új bean példányt ad vissza.

egy Másik módja annak, hogy hozzon létre a konfiguráció a bab keresztül XML konfigurációs:

Szetter-Alapú Függőség Injekció

szetter-alapú DI, a tartály hívja szetter módszerek a osztály után hivatkozva nem érv, kivitelező, vagy nem érv, statikus gyári módszer a standard input a bab., Hozzuk létre ezt a konfigurációt kommentárokkal:

@Beanpublic Store store() { Store store = new Store(); store.setItem(item1()); return store;}

a babok azonos konfigurációjához XML-t is használhatunk:

<bean class="org.baeldung.store.Store"> <property name="item" ref="item1" /></bean>

konstruktor alapú és szetter alapú befecskendezési típusok kombinálhatók ugyanarra a babra. A tavaszi dokumentáció azt javasolja, hogy konstruktor alapú befecskendezést használjunk a kötelező függőségekhez, a szetter alapú befecskendezést pedig az opcionális injekciókhoz.

7., Mező-Alapú Függőség Injekció

ha a Mező Alapú DI, mi lehet beadni a függőségek megjelölésével őket egy @Autowired jegyzet:

public class Store { @Autowired private Item item; }

Míg építése a Bolt tárgy, ha nincs konstruktor vagy szetter módszer adja a Tétel bean, a tartály fogja használni tükrözi, hogy adja be a tárgyat Tárolni.

ezt XML konfigurációval is elérhetjük.,

Ez a megközelítés egyszerűbbnek és tisztábbnak tűnhet, de nem ajánlott használni, mert van néhány hátránya, mint például:

• ez a módszer reflexiót használ a függőségek befecskendezésére,ami költségesebb, mint a konstruktor-alapú vagy szetter-alapú injekció
• ez a megközelítés nagyon könnyű több függőséget hozzáadni. Ha több érvvel rendelkező konstruktorinjekciót használna, azt gondolnánk, hogy az osztály egynél több dolgot tesz, ami megsértheti az egyetlen felelősség elvét.,

További információ a @ Autowired kommentárról a tavaszi cikkben található.

Autowiring függőségek

a huzalozás lehetővé teszi a Rugótartály számára, hogy automatikusan megoldja a babok közötti függőségeket a definiált babok ellenőrzésével.,

négy mód a autowiring egy bean segítségével egy XML konfigurációs:

• nem: az alapértelmezett érték – ez azt jelenti, hogy nem autowiring használják a bab van, hogy kifejezetten neve a függőségek
• byName: autowiring alapján történik a nevét a szállás, ezért lesz a Tavasz nézd meg a bab ugyanaz a neve, mint az ingatlan, amit meg kell beállítani
• byType: hasonló a byName autowiring, csak az alapján, hogy milyen típusú ingatlant. Ez azt jelenti, hogy a tavasz olyan babot fog keresni, amely ugyanolyan típusú tulajdonsággal rendelkezik., Ha egynél több ilyen típusú bab van, a keret kivételt képez.,is adja be a babot használja a @Autowired jegyzet a autowiring által típus:

  public class Store { @Autowired private Item item;}

  Ha több, mint egy babszem, azonos típusú, tudjuk használni a @Selejtező jegyzet a referencia-egy bean név szerint:

  public class Store { @Autowired @Qualifier("item1") private Item item;}

  Most, hadd autowire bab típus szerinti keresztül XML konfigurációs:

  <bean class="org.baeldung.store.Store" autowire="byType"> </bean>

  a Következő adjuk be egy bean nevű elem elem tulajdonsága tárolja bean név keresztül XML:

  <bean class="org.baeldung.store.ItemImpl1" /><bean class="org.baeldung.store.Store" autowire="byName"></bean>

  Mi is felülbírálja a autowiring meghatározásával függőségek kifejezetten keresztül kivitelező érvek vagy alkotóinak.,

  lusta inicializált bab

  alapértelmezés szerint a tároló létrehozza és konfigurálja az összes singleton babot az inicializálás során. Ennek elkerülése érdekében használhatja a lusta-init attribútumot true értékkel a bean konfigurációban:

  <bean class="org.baeldung.store.ItemImpl1" lazy-init="true" />

  ennek következtében az item1 bean csak akkor inicializálódik, amikor először kérik, nem pedig indításkor., Ennek előnye a gyorsabb inicializálási idő, de a kompromisszum az, hogy a konfigurációs hibákat csak a bean kérése után lehet felfedezni, ami több órával vagy akár nappal az alkalmazás már futása után is lehet.

  Következtetés

  ebben A cikkben már bemutatott a fogalmak inverzió, az ellenőrzés függőség injekció példázta őket a Tavaszi keret.

  ezekről a fogalmakról Bővebben Martin Fowler cikkeiben olvashat:

  • a Vezérlőtárolók inverziója és a függőségi befecskendezési minta.,
  • a kontroll inverziója