La primavera è per i pigri. Fondamenti, concetti di base ed esempi con codice. Parte 1

Molte persone, dopo aver letto i miei articoli sulla creazione di un modello per un progetto web e sulla creazione di un semplice servizio web utilizzando le servlet , si sono chieste quando avrei scritto di Spring. Non volevo, ho suggerito di leggere un libro (e continuo a dire che un libro è meglio di 10, o anche 100 articoli su Internet). Ma ora ho deciso che per spiegare la stessa cosa a persone diverse, passo più tempo che se mi sedessi una volta e scrivessi un articolo, e poi pubblicassi semplicemente un collegamento ad esso. Quindi scrivo per il bene del collegamento)). In questo articolo non scriverò come realizzare un progetto funzionante in Primavera in 5 minuti seguendo il mio esempio. Scriverò solo di cose basilari, senza la cui conoscenza è certamente possibile avviare un progetto, ma cosa sta succedendo lì e, soprattutto, perché, non sarà chiaro.

Cos'è Spring Framework?

Spring Framework , o semplicemente Spring , è uno dei framework più diffusi per la creazione di applicazioni web in Java. Un framework è qualcosa di simile a una libreria (forse questo termine ti è più familiare), ma c'è un punto. In parole povere, utilizzando una libreria, crei semplicemente oggetti delle classi in essa contenute, chiami i metodi di cui hai bisogno e quindi ottieni il risultato di cui hai bisogno. Cioè, esiste un approccio più imperativo: indichi chiaramente nel tuo programma in quale momento specifico devi creare quale oggetto, in quale momento devi chiamare un metodo specifico, ecc. Con i framework le cose sono leggermente diverse. Scrivi semplicemente alcune delle tue classi, scrivi lì parte della logica e il framework stesso crea oggetti delle tue classi e chiama metodi per te. Molto spesso, le tue classi implementano alcune interfacce dal framework o ne ereditano alcune, ricevendo così alcune funzionalità già scritte per te. Ma non deve essere così. In Spring, ad esempio, cercano di allontanarsi il più possibile da un accoppiamento così rigido (quando le classi dipendono direttamente da alcune classi/interfacce di questo framework) e utilizzano le annotazioni per questo scopo. Torneremo su questo punto più tardi. Ma è importante capire che Spring è solo un insieme di alcune classi e interfacce che sono già state scritte per te :) Voglio anche notare subito che Spring può essere utilizzato non solo per le applicazioni web, ma anche per le console più comuni applicazioni che sono così familiari a tutti noi programmi E oggi scriveremo anche qualcosa del genere.

Struttura

Ma la primavera non è un quadro specifico. Questo è piuttosto un nome generico per una serie di piccoli framework, ognuno dei quali svolge un tipo di lavoro diverso. Come puoi vedere, la molla ha una struttura modulare. Questo ci permette di connettere solo i moduli che ci servono per la nostra applicazione e non collegare quelli che ovviamente non utilizzeremo. Per quanto ne so, fu questo approccio che aiutò Spring a superare il suo concorrente dell'epoca (EJB) e prendere il comando. Perché le applicazioni che utilizzano EJB portavano con sé molte dipendenze e in generale si sono rivelate lente e goffe. L'immagine mostra che il quadro primaverile è composto da diversi moduli:

• accesso ai dati;
• ragnatela;
• nucleo;
• e altri.

Oggi faremo conoscenza con alcuni concetti del modulo principale, come: bean, contesto e altri. Come puoi immaginare, il modulo di accesso ai dati contiene strumenti per lavorare con i dati (principalmente database), web - per lavorare sulla rete (inclusa la creazione di applicazioni web, di cui parleremo più avanti). Inoltre c'è anche la cosiddetta infrastruttura Spring completa: molti altri progetti che non sono ufficialmente inclusi nel framework stesso, ma sono perfettamente integrati nel progetto Spring (ad esempio, la stessa sicurezza Spring per lavorare con l'autorizzazione dell'utente sul sito, che, spero, sentiremo anche noi un giorno).

Perché la primavera a Giava?

Beh, a parte il fatto che è alla moda, stiloso e giovanile, posso subito dire che appena lo imparerai anche un po', capirai quanto lavoro diverso non devi fare adesso, e quanto la Primavera assume. Puoi scrivere un paio di dozzine di righe di configurazioni, scrivere un paio di classi e otterrai un progetto funzionante. Ma non appena inizi a pensare a quanto c'è "sotto il cofano", quanto lavoro viene svolto e quanto codice dovrebbe essere scritto se facessi lo stesso progetto su semplici servlet o su socket e Java puro - ti si rizzano i capelli :) Esiste anche un'espressione del genere, come la "magia" della primavera. Questo è quando vedi che tutto funziona, ma stimi approssimativamente quanto deve accadere lì affinché tutto funzioni e come funziona lì - allora sembra che tutto questo stia accadendo davvero grazie a una sorta di magia)) È più facile da chiamatelo tutto magico piuttosto che provare a spiegare come è tutto interconnesso lì. sorridi data_ web-mvc_ security_ solo le basi.

DI/IoC

Se hai provato a leggere qualcosa su Spring, probabilmente la prima cosa che hai trovato sono state queste lettere: DI/IoC . Ora ti consiglio vivamente di prenderti una pausa da questo articolo e di leggere questo articolo su Habré ! IoC (Inversion of Control) - inversione del controllo. Ne ho già parlato di sfuggita quando ho scritto che quando usi una libreria, tu stesso scrivi nel tuo codice quale metodo di quale oggetto chiamare e, nel caso dei framework, molto spesso il framework chiamerà il codice che hai scritto a destra momento. Cioè qui non controlli più il processo di esecuzione del codice/programma, ma il framework lo fa per te. Gli hai trasferito il controllo (inversione del controllo). DI è inteso come Inversione delle dipendenze (inversione delle dipendenze, ovvero tentativi di non stabilire connessioni rigide tra i moduli/classi, in cui una classe è direttamente collegata a un'altra) o Iniezione delle dipendenze (iniezione delle dipendenze, questo è quando gli oggetti cat non sono creati principalmente da te e poi li passi ai tuoi metodi, e Spring li crea per te, e tu gli dici semplicemente qualcosa come "Voglio prendere un gatto qui" e lui te lo passa nel tuo metodo). Incontreremo più spesso il secondo in ulteriori articoli.

Fagioli e contesto

Uno dei concetti chiave della primavera è il fagiolo . In sostanza, è solo un oggetto di qualche classe. Diciamo che per il nostro programma dobbiamo utilizzare 3 oggetti: un gatto, un cane e un pappagallo. E abbiamo un sacco di classi con un sacco di metodi, dove a volte abbiamo bisogno di un gatto per un metodo e di un cane per un altro metodo, e talvolta avremo metodi in cui abbiamo bisogno di un gatto e un pappagallo (ad esempio, un metodo per dare da mangiare a un gatto, hehe) e in alcuni metodi saranno necessari tutti e tre gli oggetti. Sì, possiamo prima creare questi tre oggetti nel main, quindi passarli alle nostre classi e dall'interno delle classi ai metodi che ci servono... E così via in tutto il programma. E se immaginiamo anche di voler modificare periodicamente l'elenco dei parametri accettati per i nostri metodi (beh, abbiamo deciso di riscrivere qualcosa o aggiungere funzionalità), allora dovremo apportare molte modifiche al codice se necessario cambia qualcosa. Ora, cosa succede se immaginiamo di avere non 3, ma 300 oggetti di questo tipo? Un'alternativa è raccogliere tutti questi oggetti in un elenco comune di oggetti ( List<Object> ) e passarlo a tutti i metodi e dall'interno dei metodi ottenere questo o quell'oggetto di cui abbiamo bisogno. Ma cosa succede se immaginiamo che man mano che il programma procede, qualche oggetto potrebbe essere aggiunto a questa lista o (cosa peggio) cancellato? Quindi in tutti i metodi in cui recuperiamo oggetti dall'elenco in base al loro indice, tutto può rompersi. Quindi decidiamo di memorizzare non un elenco, ma una mappa, dove la chiave sarà il nome dell'oggetto di cui abbiamo bisogno, e il valore sarà l'oggetto stesso, e quindi potremo ottenere da esso gli oggetti di cui abbiamo bisogno semplicemente con il loro nome : get("parrot") e in risposta abbiamo ricevuto un oggetto parrot Oppure, ad esempio, la chiave è la classe dell'oggetto, e il valore è l'oggetto stesso, quindi non possiamo più indicare il nome dell'oggetto, ma semplicemente la classe dell'oggetto che ci serve, il che è anche comodo. O anche scrivere una sorta di wrapper sulla mappa, in cui è possibile creare metodi in modo che in alcuni casi sia possibile recuperare gli oggetti per nome e in altri casi per classe. Questo è ciò che otteniamo dal contesto dell'applicazione spring . Un contesto è un insieme di bean (oggetti). Passando al contesto, possiamo ottenere il bean (oggetto) di cui abbiamo bisogno tramite il suo nome, ad esempio, o tramite il suo tipo, o qualcos'altro. Inoltre possiamo chiedere a Spring di andare a cercare il bean di cui abbiamo bisogno nel suo contesto e di passarlo al nostro metodo. Ad esempio, se avessimo un metodo come questo:

public void doSomething(Cat cat) {
    ...
}

Quando Spring ha chiamato questo metodo per noi, ha trasferito l'oggetto del nostro gatto dal suo contesto ad esso. Ora decidiamo che il nostro metodo, oltre ad un gatto, necessita anche di un pappagallo. Usare la primavera: per noi niente è più facile! Scriviamo semplicemente:

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

e Spring, quando chiamerà questo nostro metodo, capirà che dobbiamo passare qui un gatto e un pappagallo, andare nel suo contesto, prendere questi due oggetti e passarli al nostro metodo. Consegnando le redini del nostro programma a Spring, abbiamo trasferito a lui anche la responsabilità di creare oggetti e di passarli ai nostri metodi, che chiamerà. La domanda sorge spontanea: come farà Spring a sapere quali oggetti (contenitori) creare?

Metodi di configurazione dell'applicazione

Esistono tre modi principali per configurare un'applicazione (ovvero, dire a Spring quali oggetti abbiamo bisogno per funzionare):

1. utilizzando file/configurazioni xml;
2. utilizzando le configurazioni Java;
3. configurazione automatica.

Gli sviluppatori di Spring li organizzano in questo ordine di priorità:

• il metodo più prioritario a cui dare la preferenza è la configurazione automatica;
• se utilizzando la configurazione automatica non è possibile configurare correttamente tutti i bean possibili, utilizzare la configurazione Java (creando oggetti utilizzando il codice Java);
• Bene, il modo con la priorità più bassa è quello vecchio stile, utilizzando le configurazioni xml.

Inoltre, Spring ti consente di combinare questi metodi. Ad esempio, lascia che Spring faccia tutto ciò che può essere configurato automaticamente; dove è necessario specificare alcuni parametri speciali, fallo utilizzando le configurazioni Java e, inoltre, puoi connettere alcune configurazioni legacy in formato xml. In generale, tutto ciò può essere fatto in modo abbastanza flessibile. Tuttavia, se tutto può essere fatto utilizzando le impostazioni automatiche, usalo. Considererò solo la configurazione automatica e le configurazioni Java; Le configurazioni xml sono già utilizzate in quasi tutti gli esempi Spring su Internet e, una volta compreso come funziona la configurazione Java, non dovrebbero esserci problemi a "leggere" un file xml che fa la stessa cosa. La configurazione automatica viene utilizzata quando gli oggetti di cui abbiamo bisogno per lavorare sono oggetti di classi che abbiamo scritto . Se è necessaria una logica molto specifica per creare un oggetto della nostra classe, o se non abbiamo la possibilità di contrassegnare qualche classe con l'annotazione di cui abbiamo bisogno, che verrebbe rilevata dalla configurazione automatica, questo può essere fatto nelle configurazioni Java . Nella parte successiva , creeremo un progetto esperto, collegheremo ad esso un paio di moduli a molla centrali e creeremo i nostri primi fagioli.