Java / Spring - The Beans Factory

Redan efter att ha gått igenom alla mina självstudier av förberedelser inför vårramen, äntligen kommer vi att förstå vad det gör Vår som sådan. Om du börjar läsa den här självstudien och går vilse, rekommenderar jag att du läser dessa fyra självstudier i denna ordning:

• Java / Spring - Arv, polymorfism och beroendeinsprutning
• Java / Spring - Arv, polymorfism och beroendeinsprutning - Del 2
• Java / Spring - Programmeringsgränssnitt
• Inversion av kontroll och beroendeinsprutning i Java / Spring

När du väl förstår dessa begrepp kan du fortsätta med den här självstudien. För att starta denna handledning kommer vi att prata om hur våren fungerar.
Våren är en behållare med bönor (Jag kommer att använda detta ord för att hänvisa till denna typ av struktur under hela denna handledning och de som följer), en böna är en återanvändbar programvarukomponent. I Java är en böna ett objekt som existerar för att fylla en specifik funktion och är också den klass som objektet tillhör. Bönor i Java skapas av beskrivningar som inte nödvändigtvis ingår i huvudprogramkoden, dessa beskrivningar finns vanligtvis i XML -filer.
När du använder Spring manipuleras livscykeln för varje böna helt av vårbehållaren, som är ansvarig för att skapa, hantera och förstöra dem från ett standardmönster som finns i en XML -fil, inuti Java -klassen i formen Annotations eller i princip vilken typ av fil som helst som följer ett visst format för dess definition.
På detta sätt innebär konceptet Inversion of Control att Spring skapar objekten och konfigurerar dem för att uppfylla en specifik funktion (enligt standardmönstret) och sedan levererar dem till huvudapplikationen. Senare tar vården hand om att förstöra dem eller återanvända dem på en mer avancerad punkt i applikationen. Det gör detta genom att använda ett visst designmönster.
Ett konstruktionsmönster av fabrikstyp kännetecknas av att det inte är knutet till att returnera en specifik klass av objekt utan snarare ett objekt som implementerar ett gränssnitt eller ärver från en viss klass. På detta sätt kan fabriken returnera praktiskt taget vad som helst så länge det kan "tillverka" det specifika föremålet. När det gäller våren returnerar fabriksmetoden ett objekt av typ Objekt som senare omvandlas till den typ av objekt som krävs av huvudprogrammet.
Specifikt kallar huvudprogrammet fabriksmetoden för att förse det med ett specifikt objekt som det inte kontrollerar men tillhör Spring så att det kan användas utan att "ta ansvar" för objektet. På det sättet har våren alltid ansvaret för objektets livscykel ALLTID.

FÖRSTORA

Det är så våren hanterar konceptet Inversion of Control and Dependency Injection. I princip skapar du de bönor du behöver under hela ditt program i form av enkla Java -klasser, med attribut, getters och setters. Sedan skapar du en konfigurationsfil som är ansvarig för att skapa de specifika POJO: erna (vanliga gamla Java -objekt) för användning i hela programmet och slutligen låter du våren ta hand om livscykeln för alla dessa objekt under väder.
Denna struktur är ganska praktisk för att utföra tester i koden med "falska" objekt, den tjänar också till att underhålla aktiva tjänster som anropas via nätverket, använder aspekter och otaliga andra saker. På vårsidan kan du granska alla projekt som har kommit fram från denna ram. Jag hoppas att du tyckte det var intressant, glöm inte att lämna dina kommentarer. Vi ses nästa gång!Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng