Wat is die voordele van afhanklikheidsinspuitingshouers?

https://stackoverflow.com/questions/131975

02-07-2019
|

Vra

Ek verstaan die voordele van afhanklikheidsinspuiting self.Kom ons neem die lente as voorbeeld.Ek verstaan ook die voordele van ander Spring-kenmerke soos AOP, helpers van verskillende soorte, ens.Ek wonder net, wat is die voordele van XML-konfigurasie soos:

<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

in vergelyking met gewone ou java-kode soos:

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

wat makliker ontfout kan word, saamsteltyd nagegaan en verstaan kan word deur enigiemand wat net java ken.So wat is die hoofdoel van 'n afhanklikheidsinspuitingsraamwerk?(of 'n stukkie kode wat die voordele daarvan toon.)

OPDATEER:
In die geval van

IService myService;// ...
public void doSomething() {  
  myService.fetchData();
}

Hoe kan IoC-raamwerk raai watter implementering van myService ek wil ingespuit word as daar meer as een is?As daar net een implementering van gegewe koppelvlak is, en ek laat IoC-houer outomaties besluit om dit te gebruik, sal dit gebreek word nadat 'n tweede implementering verskyn het.En as daar doelbewus net een moontlike implementering van 'n koppelvlak is, hoef u dit nie in te spuit nie.

Dit sal regtig interessant wees om 'n klein stukkie konfigurasie vir IoC te sien wat die voordele daarvan toon.Ek gebruik Spring al 'n rukkie en ek kan nie so 'n voorbeeld verskaf nie.En ek kan enkele reëls wys wat die voordele van hibernate, dwr en ander raamwerke wat ek gebruik demonstreer.

OPDATERING 2:
Ek besef dat IoC-konfigurasie verander kan word sonder om te hersaamstel.Is dit regtig so 'n goeie idee?Ek kan verstaan wanneer iemand DB geloofsbriewe wil verander sonder om te hersaamstel - hy is dalk nie ontwikkelaar nie.In jou praktyk, hoe gereeld verander iemand anders as ontwikkelaar IoC-konfigurasie?Ek dink dat daar vir ontwikkelaars geen poging is om daardie spesifieke klas te hersaamstel in plaas van om konfigurasie te verander nie.En vir nie-ontwikkelaars sal jy waarskynlik sy lewe makliker wil maak en 'n eenvoudiger konfigurasielêer verskaf.

OPDATERING 3:

Eksterne konfigurasie van kartering tussen koppelvlakke en hul konkrete implementerings

Wat is so goed om dit uiterlik te maak?Jy maak nie al jou kode ekstern nie, terwyl jy beslis kan - plaas dit net in die ClassName.java.txt-lêer, lees en stel met die hand saam - sjoe, jy het hersamestelling vermy.Hoekom moet samestelling vermy word?!

Jy spaar koderingstyd omdat jy karterings verklarend verskaf, nie in 'n prosedurele kode nie

Ek verstaan dat soms verklarende benadering tyd bespaar.Byvoorbeeld, ek verklaar slegs een keer 'n kartering tussen 'n boontjie-eienskap en 'n DB-kolom en hiberneer gebruik hierdie kartering terwyl laai, stoor, bou van SQL gebaseer op HSQL, ens.Dit is waar die verklarende benadering werk.In die geval van Lente (in my voorbeeld), het verklaring meer reëls gehad en het dieselfde ekspressiwiteit as ooreenstemmende kode gehad.As daar 'n voorbeeld is wanneer so 'n verklaring korter as kode is - sal ek dit graag wil sien.

Inversie van beheer-beginsel maak voorsiening vir maklike eenheidstoetsing omdat jy werklike implementerings kan vervang met valse (soos om SQL-databasis te vervang met 'n in-geheue een)

Ek verstaan wel omkering van beheervoordele (ek verkies om die ontwerppatroon wat hier bespreek word as Afhanklikheidsinspuiting te noem, want IoC is meer algemeen - daar is baie soorte beheer, en ons keer net een van hulle om - beheer van inisialisering).Ek het gevra hoekom iemand ooit iets anders as 'n programmeertaal daarvoor nodig het.Ek kan beslis regte implementerings vervang met valse implementerings deur kode te gebruik.En hierdie kode sal dieselfde ding as konfigurasie uitdruk - dit sal net velde met vals waardes inisialiseer.

mary = new FakeFemale();

Ek verstaan wel die voordele van DI.Ek verstaan nie watter voordele deur eksterne XML-konfigurasie bygevoeg word in vergelyking met die opstel van kode wat dieselfde doen nie.Ek dink nie dat samestelling vermy moet word nie – ek stel elke dag saam en ek leef nog.Ek dink konfigurasie van DI is 'n slegte voorbeeld van verklarende benadering.Verklaring kan nuttig wees as dit een keer verklaar word EN word baie keer op verskillende maniere gebruik - soos hibernate cfg, waar kartering tussen boontjie-eienskap en DB-kolom gebruik word vir stoor, laai, bou van soeknavrae, ens.Spring DI-konfigurasie kan maklik vertaal word na konfigurasiekode, soos in die begin van hierdie vraag, nie waar nie?En dit word net vir boontjie-inisialisering gebruik, is dit nie?Wat beteken dat 'n verklarende benadering niks hier byvoeg nie, of hoe?

Wanneer ek hibernate kartering verklaar, gee ek net hibernate inligting, en dit werk op grond daarvan - ek sê nie vir hom wat om te doen nie.In die geval van lente, vertel my verklaring die lente presies wat om te doen - so hoekom dit verklaar, hoekom doen dit nie net nie?

LAASTE OPDATERING:
Ouens, baie antwoorde vertel my van afhanklikheidsinspuiting, wat ek WEET GOED IS.Die vraag gaan oor die doel van DI-konfigurasie in plaas van om kode te initialiseer - ek is geneig om te dink dat inisialiseringskode korter en duideliker is.Die enigste antwoord wat ek tot dusver op my vraag gekry het, is dat dit hersamestelling vermy wanneer die konfigurasie verander.Ek dink ek moet nog 'n vraag plaas, want dit is 'n groot geheim vir my, hoekom samestelling in hierdie geval vermy moet word.

Oplossing

Vir myself is een van die hoofredes om 'n IoC te gebruik (en van eksterne konfigurasie gebruik te maak) rondom die twee areas van:

Toets
Produksie instandhouding

Toets

As jy jou toetsing in 3 scenario's verdeel (wat redelik normaal is in grootskaalse ontwikkeling):

Eenheid toetsing
Integrasie toets
Swart boks toets

Wat jy sal wil doen, is om vir die laaste twee toetsscenario's (Integrasie & Black Box), geen deel van die toepassing te hersaamstel nie.

As enige van jou toetsscenario's vereis dat jy die konfigurasie verander (bv.gebruik 'n ander komponent om 'n bankintegrasie na te boots, of om 'n prestasielading te doen), kan dit maklik hanteer word (dit kom egter onder die voordele van die konfigurasie van die DI-kant van 'n IoC.

As jou program ook op verskeie werwe gebruik word (met verskillende bediener- en komponentkonfigurasie) of 'n veranderende opstelling op die lewendige omgewing het, kan jy die latere stadiums van toetsing gebruik om te verifieer dat die program daardie veranderinge sal hanteer.

Produksie

As 'n ontwikkelaar het jy nie (en behoort nie) beheer oor die produksie-omgewing te hê nie (veral wanneer jou toepassing na veelvuldige klante of afsonderlike werwe versprei word), is dit vir my die werklike voordeel van die gebruik van beide 'n IoC en eksterne konfigurasie , want dit is aan die infrastruktuur/produksie-ondersteuning om die lewendige omgewing aan te pas en aan te pas sonder om terug te gaan na ontwikkelaars en deur toets (hoër koste wanneer al wat hulle wil doen is om 'n komponent te skuif).

Opsomming

Die belangrikste voordele van eksterne konfigurasie van 'n IoC is om ander (nie-ontwikkelaars) die krag te gee om u toepassing op te stel, volgens my ervaring is dit slegs nuttig onder 'n beperkte stel omstandighede:

Toepassing word na veelvuldige werwe/kliënte versprei waar omgewings sal verskil.
Beperkte ontwikkelingsbeheer/insette oor die produksie-omgewing en opstelling.
Toets scenario's.

In die praktyk het ek gevind dat selfs wanneer jy iets ontwikkel wat jy wel beheer oor die omgewing het, dit mettertyd beter is om iemand anders die vermoë te gee om die konfigurasie te verander:

Wanneer jy ontwikkel, weet jy nie wanneer dit sal verander nie (die toepassing is so nuttig dat jou maatskappy dit aan iemand anders verkoop).
Ek wil nie vasstaan met die verandering van die kode elke keer as 'n effense verandering versoek word wat hanteer kon word deur 'n goeie konfigurasiemodel op te stel en te gebruik nie.

Let wel:Toepassing verwys na die volledige oplossing (nie net die uitvoerbare nie), dus alle lêers wat nodig is vir die toepassing om te laat loop.

Ander wenke

Afhanklikheidsinspuiting is 'n koderingstyl wat sy wortels het in die waarneming dat objekdelegering gewoonlik 'n meer bruikbare ontwerppatroon is as objekoorerwing (m.a.w. die objek het-'n verhouding is nuttiger as wat die voorwerp 'n verhouding is).Een ander bestanddeel is egter nodig vir DI om te werk, dié van die skep van objek-koppelvlakke.Deur hierdie twee kragtige ontwerppatrone te kombineer, het sagteware-ingenieurs vinnig besef dat hulle buigsame losgekoppelde kode kon skep en dus is die konsep van Afhanklikheidsinspuiting gebore.Dit was egter eers toe voorwerprefleksie in sekere hoëvlaktale beskikbaar geword het dat DI werklik posgevat het.Die refleksie-komponent is die kern van die meeste van vandag se DI-stelsels vandag omdat die werklik cool aspekte van DI die vermoë vereis om voorwerpe programmaties te selekteer en dit op te stel en in ander voorwerpe in te spuit deur 'n stelsel wat ekstern en onafhanklik van die voorwerpe self is, te gebruik.

'n Taal moet goeie ondersteuning bied vir beide normale objekgeoriënteerde programmeringstegnieke sowel as ondersteuning vir objekkoppelvlakke en objekrefleksie (byvoorbeeld Java en C#).Alhoewel u programme kan bou deur DI-patrone in C++-stelsels te gebruik, verhoed die gebrek aan refleksie-ondersteuning binne die regte taal dit om toepassingsbedieners en ander DI-platforms te ondersteun en beperk dus die ekspressiwiteit van die DI-patrone.

Sterkpunte van 'n stelsel wat met DI-patrone gebou is:

DI-kode is baie makliker om te hergebruik aangesien die 'afhanklike' funksionaliteit in goed gedefinieerde koppelvlakke geëkstrapoleer word, wat toelaat dat afsonderlike voorwerpe waarvan die konfigurasie deur 'n geskikte toepassingsplatform hanteer word, na goeddunke by ander voorwerpe ingeprop kan word.
DI-kode is baie makliker om te toets.Die funksionaliteit wat deur die voorwerp uitgedruk word, kan in 'n swart boks getoets word deur 'bespotlike' voorwerpe te bou wat die koppelvlakke wat deur jou toepassingslogika verwag word, implementeer.
DI-kode is meer buigsaam.Dit is aangebore losgekoppelde kode -- tot 'n uiterste.Dit laat die programmeerder toe om te kies en te kies hoe voorwerpe verbind word, uitsluitlik op grond van hul vereiste koppelvlakke aan die een kant en hul uitgedrukte koppelvlakke aan die ander kant.
Eksterne (Xml) konfigurasie van DI-voorwerpe beteken dat ander jou kode in onvoorsiene rigtings kan pasmaak.
Eksterne konfigurasie is ook 'n skeiding van kommer patroon deurdat alle probleme van objek inisialisering en objek interafhanklikheid bestuur deur die toepassing bediener hanteer kan word.
Let daarop dat eksterne konfigurasie nie nodig is om die DI-patroon te gebruik nie, vir eenvoudige onderlinge verbindings is 'n klein bouer-objek dikwels voldoende.Daar is 'n kompromis in buigsaamheid tussen die twee.'n Bouervoorwerp is nie so buigsaam 'n opsie soos 'n ekstern sigbare konfigurasielêer nie.Die ontwikkelaar van die DI-stelsel moet die voordele van buigsaamheid bo gerief opweeg, en sorg dat kleinskaalse fynkorrelbeheer oor objekkonstruksie soos uitgedruk in 'n konfigurasielêer verwarring en onderhoudskoste verder kan verhoog.

DI-kode lyk beslis meer omslagtig, die nadele om al daardie XML-lêers te hê wat voorwerpe konfigureer om in ander voorwerpe ingespuit te word, lyk moeilik.Dit is egter die punt van DI-stelsels.Jou vermoë om kode-objekte te meng en te pas as 'n reeks konfigurasie-instellings stel jou in staat om komplekse stelsels te bou deur derdeparty-kode te gebruik met minimale kodering van jou kant.

Die voorbeeld wat in die vraag verskaf word, raak bloot die oppervlak van die uitdrukkingskrag wat 'n behoorlik gefaktoriseerde DI-objekbiblioteek kan verskaf.Met 'n bietjie oefening en baie selfdissipline vind die meeste DI-praktisyns dat hulle stelsels kan bou wat 100% toetsdekking van toepassingskode het.Hierdie een punt alleen is buitengewoon.Dit is nie 100% toetsdekking van 'n klein toepassing van 'n paar honderd reëls kode nie, maar 100% toetsdekking van toepassings wat honderde duisende reëls kode bevat.Ek kan nie enige ander ontwerppatroon beskryf wat hierdie vlak van toetsbaarheid bied nie.

Jy is korrek in die sin dat 'n toepassing van slegs 10'e reëls kode makliker is om te verstaan as verskeie voorwerpe plus 'n reeks XML-konfigurasielêers.Soos met kragtigste ontwerppatrone, word die winste egter gevind as jy voortgaan om nuwe kenmerke by die stelsel te voeg.

Kortom, grootskaalse DI-gebaseerde toepassings is makliker om te ontfout en makliker om te verstaan.Alhoewel die XML-konfigurasie nie 'saamsteltyd nagegaan' is nie, sal alle toepassingsdienste waarvan hierdie skrywer bewus is, die ontwikkelaar van foutboodskappe voorsien as hulle probeer om 'n voorwerp met 'n onversoenbare koppelvlak in 'n ander voorwerp in te spuit.En die meeste bied 'n 'kontrole'-kenmerk wat alle bekende voorwerpkonfigurasies dek.Dit word maklik en vinnig gedoen deur te kontroleer dat die voorwerp A wat ingespuit moet word die koppelvlak wat deur objek B vereis word vir alle gekonfigureerde voorwerpinspuitings implementeer.

Dit is 'n bietjie van 'n gelaaide vraag, maar ek is geneig om saam te stem dat groot hoeveelhede xml-konfigurasie nie regtig tot veel voordeel inhou nie.Ek hou daarvan dat my toepassings so lig as moontlik op afhanklikhede is, insluitend die stewige raamwerke.

Hulle vereenvoudig die kode baie van die kere, maar hulle het ook 'n oorhoofse kompleksiteit wat dit moeilik maak om probleme op te spoor (ek het sulke probleme eerstehands gesien, en reguit Java sal ek baie gemakliker wees om te hanteer).

Ek dink dit hang 'n bietjie af van styl, en waarmee jy gemaklik is ...hou jy daarvan om jou eie oplossing te vlieg en het jy die voordeel om dit van binne te ken, of om op bestaande oplossings te bank wat dalk moeilik kan wees as die konfigurasie nie net reg is nie?Dit is alles 'n kompromis.

XML-konfigurasie is egter 'n bietjie van 'n troeteldier van my ...Ek probeer dit ten alle koste vermy.

Enige tyd wat jy jou kode na data kan verander, maak jy 'n stap in die regte rigting.

Om enigiets as data te kodeer beteken dat jou kode self meer algemeen en herbruikbaar is.Dit beteken ook dat jou data gespesifiseer kan word in 'n taal wat presies daarby pas.

'n XML-lêer kan ook in 'n GUI of 'n ander hulpmiddel gelees word en maklik pragmaties gemanipuleer word.Hoe sou jy dit doen met die kodevoorbeeld?

Ek is voortdurend besig om dinge te faktoriseer wat die meeste mense as kode in data sou implementeer, dit maak die kode wat gelaat word BAIE skoner.Ek vind dit ondenkbaar dat mense 'n spyskaart in kode eerder as as data sal skep - dit behoort duidelik te wees dat dit eenvoudig verkeerd is om dit in kode te doen as gevolg van die boilerplate.

Die rede vir die gebruik van 'n DI-houer is dat jy nie 'n miljard eiendomme vooraf in jou kode hoef te hê wat bloot getters en setters is nie.Wil jy regtig almal met nuwe X() hardkodeer?Sekerlik, jy kan 'n verstek hê, maar die DI-houer laat die skepping van singletons toe wat uiters maklik is en jou toelaat om te fokus op die besonderhede van die kode, nie die diverse taak om dit te inisialiseer nie.

Byvoorbeeld, Spring laat jou toe om die InitializingBean-koppelvlak te implementeer en 'n afterPropertiesSet-metode by te voeg (jy kan ook 'n "init-metode" spesifiseer om te verhoed dat jou kode aan Spring gekoppel word).Hierdie metodes sal jou toelaat om te verseker dat enige koppelvlak wat as 'n veld in jou klasinstansie gespesifiseer is, korrek gekonfigureer is by opstart, en dan hoef jy nie meer jou getters en setters te nul-kontroleer nie (met die veronderstelling dat jy toelaat dat jou singletons draadveilig bly ).

Verder is dit baie makliker om komplekse initialiserings met 'n DI-houer te doen in plaas daarvan om dit self te doen.Ek help byvoorbeeld met die gebruik van XFire (nie CeltiXFire nie, ons gebruik net Java 1.4).Die toepassing het Spring gebruik, maar dit het ongelukkig XFire se services.xml-konfigurasiemeganisme gebruik.Wanneer 'n versameling elemente moes verklaar dat dit NUL of meer gevalle het in plaas van EEN of meer gevalle, moes ek sommige van die verskafde XFire-kode vir hierdie spesifieke diens ignoreer.

Daar is sekere XFire-standaarde wat in sy Spring beans-skema gedefinieer word.Dus, as ons Spring gebruik het om die dienste op te stel, kon die bone gebruik gewees het.In plaas daarvan, wat gebeur het, was dat ek 'n instansie van 'n spesifieke klas in die services.xml-lêer moes verskaf in plaas daarvan om die boontjies te gebruik.Om dit te doen, moes ek die konstruktor verskaf en die verwysings wat in die XFire-konfigurasie verklaar is, opstel.Die werklike verandering wat ek moes maak, het vereis dat ek 'n enkele klas oorlaai.

Maar, te danke aan die services.xml-lêer, moes ek vier nuwe klasse skep en hul verstekke stel volgens hul verstekke in die Spring-konfigurasielêers in hul konstruktors.As ons die Spring-konfigurasie kon gebruik, kon ek net gesê het:

<bean id="base" parent="RootXFireBean">
    <property name="secondProperty" ref="secondBean" />
</bean>

<bean id="secondBean" parent="secondaryXFireBean">
    <property name="firstProperty" ref="thirdBean" />
</bean>

<bean id="thirdBean" parent="thirdXFireBean">
    <property name="secondProperty" ref="myNewBean" />
</bean>

<bean id="myNewBean" class="WowItsActuallyTheCodeThatChanged" />

In plaas daarvan het dit meer soos volg gelyk:

public class TheFirstPointlessClass extends SomeXFireClass {
    public TheFirstPointlessClass() {
        setFirstProperty(new TheSecondPointlessClass());
        setSecondProperty(new TheThingThatWasHereBefore());
    }
}

public class TheSecondPointlessClass extends YetAnotherXFireClass {
    public TheSecondPointlessClass() {
        setFirstProperty(TheThirdPointlessClass());
    }
}

public class TheThirdPointlessClass extends GeeAnotherXFireClass {
    public TheThirdPointlessClass() {
        setFirstProperty(new AnotherThingThatWasHereBefore());
        setSecondProperty(new WowItsActuallyTheCodeThatChanged());
    }
}

public class WowItsActuallyTheCodeThatChanged extends TheXFireClassIActuallyCareAbout {
    public WowItsActuallyTheCodeThatChanged() {
    }

    public overrideTheMethod(Object[] arguments) {
        //Do overridden stuff
    }
}

Die netto resultaat is dus dat vier addisionele, meestal nuttelose Java-klasse by die kodebasis gevoeg moes word om die effek te bereik wat een bykomende klas en 'n paar eenvoudige afhanklikheidshouerinligting bereik het.Dit is nie die "uitsondering wat die reël bewys nie", dit IS die reël ... die hantering van eienaardighede in kode is baie skoner wanneer die eiendomme reeds in 'n DI-houer verskaf word en jy dit eenvoudig verander om by 'n spesiale situasie te pas, wat meer dikwels as nie gebeur nie.

Ek het jou antwoord

Daar is natuurlik afwykings in elke benadering, maar geëksternaliseerde XML-konfigurasielêers is nuttig vir ondernemingsontwikkeling waarin boustelsels gebruik word om die kode saam te stel en nie jou IDE nie.Deur die boustelsel te gebruik, wil jy dalk sekere waardes in jou kode invoeg - byvoorbeeld die weergawe van die bou (wat pynlik kan wees om handmatig te moet opdateer elke keer as jy saamstel).Die pyn is groter wanneer jou boustelsel kode van een of ander weergawebeheerstelsel afhaal.Om eenvoudige waardes tydens samestelling te verander, sal vereis dat jy 'n lêer verander, dit verbind, saamstel en dan elke keer vir elke verandering terugstel.Dit is nie veranderinge wat jy in jou weergawebeheer wil aanbring nie.

Ander nuttige gebruiksgevalle rakende die boustelsel en eksterne konfigurasies:

die inspuiting van style/stylblaaie vir 'n enkele kodebasis vir verskillende bouwerk
die inspuiting van verskillende stelle dinamiese inhoud (of verwysings daarna) vir jou enkele kodebasis
spuit lokalisering konteks vir verskillende geboue/kliënte
verander 'n webdiens-URI na 'n rugsteunbediener (wanneer die hoof een afgaan)

Opdateer:Al die bogenoemde voorbeelde was oor dinge wat nie noodwendig afhanklikhede van klasse vereis het nie.Maar jy kan maklik gevalle opbou waar beide 'n komplekse voorwerp en outomatisering nodig is - byvoorbeeld:

Stel jou voor dat jy 'n stelsel gehad het waarin dit die verkeer van jou webwerf gemonitor het.Afhangende van die aantal gelyktydige gebruikers, skakel dit 'n aantekenmeganisme aan/af.Miskien terwyl die meganisme af is, word 'n stompvoorwerp in sy plek gesit.
Stel jou voor dat jy 'n webkonferensiestelsel gehad het waarin jy, afhangende van die aantal gebruikers, die vermoë wil uitskakel om P2P te doen, afhangende van die aantal deelnemers

Jy hoef nie jou kode te hersaamstel elke keer as jy iets in konfigurasie verander nie.Dit sal programontplooiing en instandhouding vereenvoudig.Byvoorbeeld, jy kan een komponent met 'n ander ruil met net 1 verandering in konfigurasielêer.

Jy kan 'n nuwe implementering vir 'n vriendin insluit.So nuwe wyfie kan ingespuit word sonder om jou kode te hersaamstel.

<bean id="jane" class="foo.bar.HotFemale">
  <property name="age" value="19"/>
</bean>
<bean id="mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="john" class="foo.bar.Male">
  <property name="girlfriend" ref="jane"/>
</bean>

(Bogenoemde veronderstel Female en HotFemale implementeer dieselfde GirlfFriend-koppelvlak)

In die .NET-wêreld bied die meeste IoC-raamwerke beide XML- en Kode-konfigurasie.

StructureMap en Ninject gebruik byvoorbeeld vlot koppelvlakke om houers op te stel.Jy is nie meer beperk om XML-konfigurasielêers te gebruik nie.Spring, wat ook in .NET bestaan, maak sterk staat op XML-lêers aangesien dit sy historiese hoofkonfigurasie-koppelvlak is, maar dit is steeds moontlik om houers programmaties op te stel.

Gemak van gedeeltelike konfigurasies te kombineer in 'n finale volledige konfigurasie.

Byvoorbeeld, in webtoepassings word die model, aansig en beheerders tipies in aparte konfigurasielêers gespesifiseer.Gebruik die verklarende benadering, jy kan byvoorbeeld laai:

  UI-context.xml
  Model-context.xml
  Controller-context.xml

Of laai met 'n ander UI en 'n paar ekstra beheerders:

  AlternateUI-context.xml
  Model-context.xml
  Controller-context.xml
  ControllerAdditions-context.xml

Om dieselfde in kode te doen, vereis 'n infrastruktuur vir die kombinasie van gedeeltelike konfigurasies.Nie onmoontlik om in kode te doen nie, maar beslis makliker om te doen met behulp van 'n IoC-raamwerk.

Dikwels is die belangrike punt WHO is besig om die konfigurasie te verander nadat die program geskryf is.Met konfigurasie in kode neem jy implisiet aan dat die persoon wat dit verander dieselfde vaardighede en toegang tot bronkode ens het as wat die oorspronklike outeur gehad het.

In produksiestelsels is dit baie prakties om 'n subset van instellings te onttrek (bv.ouderdom in jou voorbeeld) na XML-lêer en laat bv.stelseladministrateur of persoonlike ondersteuning om die waarde te verander sonder om hulle die volle mag oor bronkode of ander instellings te gee - of net om hulle van kompleksiteite te isoleer.

Uit 'n lente-perspektief kan ek jou twee antwoorde gee.

Eerstens is die XML-konfigurasie nie die enigste manier om die konfigurasie te definieer nie.Die meeste dinge kan gekonfigureer word met behulp van aantekeninge en die dinge wat met XML gedoen moet word, is konfigurasie vir kode wat jy in elk geval nie skryf nie, soos 'n verbindingspoel wat jy van 'n biblioteek gebruik.Spring 3 bevat 'n metode om die DI-konfigurasie met behulp van Java te definieer soortgelyk aan die handgerolde DI-konfigurasie in jou voorbeeld.Die gebruik van Spring beteken dus nie dat jy 'n XML-gebaseerde konfigurasielêer moet gebruik nie.

Tweedens is Lente baie meer as net 'n DI-raamwerk.Dit het baie ander kenmerke, insluitend transaksiebestuur en AOP.Die Spring XML-konfigurasie meng al hierdie konsepte saam.Dikwels spesifiseer ek in dieselfde konfigurasielêer boontjiesafhanklikhede, transaksieinstellings en voeg sessie-omvangbone by wat eintlik met AOP in die agtergrond hanteer is.Ek vind die XML-konfigurasie bied 'n beter plek om al hierdie kenmerke te bestuur.Ek voel ook dat die annotasie-gebaseerde konfigurasie en XML-konfigurasie beter skaal as om Java-gebaseerde konfigurasie te doen.

Maar ek sien jou punt en daar is niks verkeerd met die definisie van die afhanklikheid-inspuiting-konfigurasie in Java nie.Ek doen dit gewoonlik self in eenheidstoetse en wanneer ek aan 'n projek werk wat klein genoeg is dat ek nie 'n DI-raamwerk bygevoeg het nie.Ek spesifiseer gewoonlik nie konfigurasie in Java nie, want dit is vir my die soort loodgieterkode wat ek probeer wegkom van skryf toe ek gekies het om Spring te gebruik.Dit is egter 'n voorkeur, dit beteken nie dat XML-konfigurasie beter is as Java-gebaseerde konfigurasie nie.

Spring het ook 'n eiendomslaaier.Ons gebruik hierdie metode om veranderlikes te stel wat afhanklik is van die omgewing (bv.ontwikkeling, toetsing, aanvaarding, produksie, ...).Dit kan byvoorbeeld die tou wees om na te luister.

As daar geen rede is waarom die eiendom sou verander nie, is daar ook geen rede om dit so op te stel nie.

Jou saak is baie eenvoudig en het dus nie 'n IoC (Inversion of Control)-houer soos Spring nodig nie.Aan die ander kant, wanneer jy "programmeer na koppelvlakke, nie implementerings nie" (wat 'n goeie praktyk in OOP is), kan jy kode soos hierdie hê:

IService myService;
// ...
public void doSomething() {
  myService.fetchData();
}

(let daarop dat die tipe myService IService is -- 'n koppelvlak, nie 'n konkrete implementering nie).Nou kan dit handig wees om jou IoC-houer outomaties die korrekte konkrete instansie van IService tydens inisialisering te laat verskaf - wanneer jy baie koppelvlakke en baie implementerings het, kan dit omslagtig wees om dit met die hand te doen.Die belangrikste voordele van 'n IoC-houer (afhanklikheidsinspuitingsraamwerk) is:

Eksterne konfigurasie van kartering tussen koppelvlakke en hul konkrete implementerings
IoC-houer hanteer 'n paar moeilike kwessies soos die oplossing van ingewikkelde afhanklikheidsgrafieke, die bestuur van komponent se leeftyd, ens.
Jy spaar koderingstyd omdat jy karterings verklarend verskaf, nie in 'n prosedurele kode nie
Inversie van beheer-beginsel maak voorsiening vir maklike eenheidstoetsing omdat jy werklike implementerings kan vervang met valse (soos om SQL-databasis te vervang met 'n in-geheue een)

Inisiasie in 'n XML-opstellingslêer sal jou ontfoutings- / aanpassingswerk vereenvoudig met 'n kliënt wat jou toepassing op hul rekenaars laat ontplooi.(Omdat dit nie hersamestelling + vervanging van binêre lêers vereis nie)

Een van die mees aanloklike redes is die "Hollywood-beginsel":moenie ons bel nie, ons sal jou bel.'n Komponent word nie vereis om self die opsoek na ander komponente en dienste te doen nie;in plaas daarvan word hulle outomaties daaraan verskaf.In Java beteken dit dat dit nie meer nodig is om JNDI-opsoeke binne die komponent te doen nie.

Dit is ook baie makliker om 'n komponent in isolasie te toets:in plaas daarvan om dit 'n werklike implementering te gee van die komponente wat dit benodig, gebruik jy eenvoudig (moontlik outomaties gegenereerde) spot.

Gelisensieer onder: CC-BY-SA met toeskrywing

Nie verbonde aan StackOverflow