Fondamentalmente la primavera è un quadro per iniezione di dipendenza che è un modello che consente di costruire sistemi molto disaccoppiati.
Il problema
Ad esempio, supponiamo di dover elencare gli utenti del sistema e quindi dichiarare un'interfaccia chiamata UserLister:
public interface UserLister {
List<User> getUsers();
}
E forse un'implementazione che accede a un database per ottenere tutti gli utenti:
public class UserListerDB implements UserLister {
public List<User> getUsers() {
// DB access code here
}
}
A tuo avviso dovrai accedere a un'istanza (solo un esempio, ricorda):
public class SomeView {
private UserLister userLister;
public void render() {
List<User> users = userLister.getUsers();
view.render(users);
}
}
Si noti che il codice sopra non ha inizializzato la variabile userLister. Cosa dovremmo fare? Se istanzio esplicitamente l'oggetto in questo modo:
UserLister userLister = new UserListerDB();
... Abbinerei la vista alla mia implementazione della classe che accede al DB. E se volessi passare dall'implementazione del DB a un altro che ottiene l'elenco utenti da un file separato da virgole (ricorda, è un esempio)? In tal caso, tornerei al mio codice e cambierei la riga sopra in:
UserLister userLister = new UserListerCommaSeparatedFile();
Questo non ha alcun problema con un piccolo programma come questo ma ... Cosa succede in un programma che ha centinaia di visualizzazioni e un numero simile di business class? La manutenzione diventa un incubo!
Approccio di primavera (iniezione di dipendenza)
Ciò che Spring fa è collegare le classi utilizzando un file XML o annotazioni, in questo modo tutti gli oggetti vengono istanziati e inizializzati da Spring e iniettati nei posti giusti (Servlet, Web Frame, Business class, DAO, ecc., Ecc., Ecc. ...).
Tornando all'esempio in primavera, dobbiamo solo avere un setter per il userListercampo e avere un file XML come questo:
<bean id="userLister" class="UserListerDB" />
<bean class="SomeView">
<property name="userLister" ref="userLister" />
</bean>
o più semplicemente annota l'archivio nella nostra classe di visualizzazione con @Inject:
@Inject
private UserLister userLister;
In questo modo, quando la vista viene creata magicamente, sarà UserListerpronta per funzionare.
List<User> users = userLister.getUsers(); // This will actually work
// without adding any line of code
È grande! No?
- Cosa succede se si desidera utilizzare un'altra implementazione della propria
UserListerinterfaccia? Basta cambiare l'XML.
- E se non fosse
UserListerpronta un'implementazione? Programmare un'implementazione fittizia temporale UserListere facilitare lo sviluppo della vista.
- E se non volessi più usare Spring? Basta non usarlo! L'applicazione non è accoppiata ad essa. Inversione del controllo afferma: "L'applicazione controlla il framework, non il framework controlla l'applicazione".
Ci sono altre opzioni per Dependency Injection lì intorno, ciò che secondo me ha reso Spring così famosa oltre alla sua semplicità, eleganza e stabilità è che i ragazzi di SpringSource hanno programmato molti POJO che aiutano a integrare Spring con molti altri framework comuni senza essere invadente nella tua applicazione. Inoltre, Spring ha molti buoni sottoprogetti come Spring MVC, Spring WebFlow, Spring Security e ancora una lista di eccipienti.
Spero che sia di aiuto. Ad ogni modo, ti incoraggio a leggere l'articolo di Martin Fowler su Iniezione di dipendenza e Inversione di controllo perché lo fa meglio di me. Dopo aver compreso le nozioni di base, dai un'occhiata alla documentazione di primavera , secondo me, è usato per essere il miglior libro di primavera di sempre.
