Skip to content

2. Articolo 1 - Spring IoC

Obiettivi del documento:

  • scoprire le possibilità di configurazione e integrazione del framework Spring (http://www.springframework.org)
  • definire e utilizzare il concetto di IoC (Inversion of Control), noto anche come iniezione di dipendenze (Dependency Injection)

2.1. Configurare un'applicazione a 3 livelli con Spring

Consideriamo un'applicazione a 3 livelli classica:

Supponiamo che l’accesso ai livelli di business e DAO sia controllato da interfacce Java:

  1. l’interfaccia [IArticlesDao] per il livello di accesso ai dati
  2. l’interfaccia [IArticlesManager] per il livello business

Nel livello di accesso ai dati o livello DAO (Data Access Object), è frequente lavorare con un SGBD e quindi con un driver JDBC. Consideriamo lo scheletro di una classe che accede a una tabella di articoli in un SGBD:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class ArticlesDaoPlainJdbc implements IArticlesDao {

     // connessione alla fonte dati
    private String driverClassName=null;
    private Connection connexion=null;
    private String url = null;
    private String user = null;
    private String pwd = null;
 ....

    public List getAllArticles() {
        // richiesta dell'elenco degli articoli
        try {
             // caricamento del driver JDBC
            Class.forName(driverClassName);
            // si crea una connessione a BD
            connexion = DriverManager.getConnection(url, user, pwd);
            ...
        } catch (SQLException ex) {
            ...
        } finally {
            ...
        }
    }

Per eseguire un'operazione sul SGBD, ogni metodo necessita di un oggetto [Connection] che rappresenti la connessione al database, attraverso la quale transiteranno gli scambi tra quest'ultimo e il codice Java. Per creare questo oggetto, sono necessarie quattro informazioni:

String driverClassName
il nome della classe del driver JDBC del SGBD
String url
l’URL JDBC del database da utilizzare
String user
l'identità con cui si crea la connessione
String pwd
la password di tale identità

Come può la nostra classe [ArticlesDaoPlainJdbc] ottenere queste informazioni? Esistono diverse possibilità:

soluzione 1 - le informazioni sono codificate in modo statico nella classe:

1
2
3
4
5
6
7
8
public class ArticlesDaoPlainJdbc implements IArticlesDao {

     // connessione alla fonte dati
    private final String driverClassName = "org.firebirdsql.jdbc.FBDriver";
    private String url = "jdbc:firebirdsql:localhost/3050:d:/databases/dbarticles.gdb";
    private String user = "someone";
    private String pwd = "somepassword";
 ....

Lo svantaggio di questa soluzione è che occorre modificare il codice Java ogni volta che si verifica una modifica di tali informazioni, ad esempio la modifica della password.

Soluzione 2 - le informazioni vengono trasmesse all'oggetto al momento della sua creazione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
public class ArticlesDaoPlainJdbc implements IArticlesDao {

     // connessione alla fonte dati
    private final String driverClassName;
    private String url;
    private String user;
    private String pwd;
 ....
    public ArticlesDaoPlainJdbc(String driverClassName,String url,String user,String pwd) {
      this.driverClassName=driverClassName;
    this.url=url;
    this.user=user;
    this.pwd=pwd;
    ...
    }

In questo caso, l’oggetto riceve al momento della sua creazione le informazioni di cui ha bisogno per funzionare. Il problema si sposta quindi sul codice che gli ha trasmesso le quattro informazioni. Come le ha ottenute? La seguente classe [ArticlesManagerWithDataBase] del livello business potrebbe creare un oggetto [ArticlesDaoPlainJdbc] del livello di accesso ai dati:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
public class ArticlesManagerWithDataBase implements IArticlesManager {

    // un'istanza di accesso ai dati
    private IArticlesDao articlesDao;
 ....
    public ArticlesManagerWithDataBase (String driverClassName, String url, String user, String pwd, ...) {
        ... 
         // creazione del servizio di accesso ai dati
        articlesDao =(IArticlesDao)new ArticlesDaoPlainJdbc(driverClassName,url,user,pwd);
    ...
    }

    public ... doSomething(...){
        ...
    }
}

Si nota che anche in questo caso le informazioni necessarie alla creazione dell’oggetto [ArticlesDaoPlainJdbc] vengono fornite al costruttore dell’oggetto [ArticlesManagerWithDataBase]. È possibile immaginare che gli vengano trasmesse da un livello superiore, come il livello di interfaccia con l’utente. Si arriva così, passo dopo passo, al livello più alto dell’applicazione. Data la sua posizione, quest’ultimo non viene chiamato da un livello che potrebbe trasmettergli le informazioni di configurazione di cui ha bisogno. È quindi necessario trovare una soluzione alternativa alla configurazione tramite costruttore. La soluzione più comune per configurare un’applicazione a livello del suo livello più alto consiste nell’utilizzare un file in cui sono contenute tutte le informazioni soggette a modifiche nel tempo. Possono esserci diversi file di questo tipo. All’avvio dell’applicazione, un livello di inizializzazione creerà quindi tutti o parte degli oggetti necessari ai diversi livelli dell’applicazione.

Esiste un’ampia varietà di file di configurazione. La tendenza attuale è quella di utilizzare file XML. È l’opzione scelta da Spring. Il file che configura un oggetto [ArticlesDaoPlainJdbc] potrebbe essere il seguente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans SYSTEM "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
     <!-- la classe di accesso ai dati -->
    <bean id="articlesDao" class="istia.st.articles.dao.ArticlesDaoPlainJdbc">
        <constructor-arg index="0">
            <value>org.firebirdsql.jdbc.FBDriver</value>
        </constructor-arg>
        <constructor-arg index="1">
            <value>jdbc:firebirdsql:localhost/3050:d:/databases/dbarticles.gdb</value>
        </constructor-arg>
        <constructor-arg index="2">
            <value>someone</value>
        </constructor-arg>
        <constructor-arg index="3">
            <value>somepassword</value>
        </constructor-arg>
    </bean>
</beans>

Un’applicazione è un insieme di oggetti che Spring chiama «bean», poiché seguono lo standard JavaBean per la denominazione dei metodi di accesso e inizializzazione (getter/setter) dei campi privati di un oggetto. Gli oggetti che, in un’applicazione, hanno il ruolo di fornire un servizio vengono spesso creati in un unico esemplare. Vengono chiamati singleton. Pertanto, nell’esempio di applicazione multi-tier qui esaminato, l’accesso al database degli articoli sarà gestito da un unico esemplare della classe [ArticlesDaoPlainJdbc]. In un’applicazione web, questi oggetti di servizio servono più clienti contemporaneamente. Non viene creato un oggetto di servizio per ogni cliente.

Il file di configurazione Spring sopra riportato consente di creare un unico oggetto di servizio di tipo [ArticlesDaoPlainJdbc] in un pacchetto denominato [istia.st.articles.dao]. Le quattro informazioni necessarie al costruttore di questo oggetto sono definite all’interno di un tag <bean>...</bean>. Si avranno tanti tag <bean> quanti sono i singleton da costruire.

Quando avviene la creazione degli oggetti definiti nel file Spring? L’inizializzazione di un’applicazione può essere affidata al metodo main della stessa applicazione, se ne possiede uno. Per un’applicazione web, potrebbe trattarsi del metodo [init] del servlet principale. In ogni applicazione è presente un metodo che viene eseguito per primo. È generalmente in questo metodo che avviene la creazione dei singleton.

Facciamo un esempio. Supponiamo di voler testare la classe [ArticlesDaoPlainJdbc] precedente utilizzando un test JUnit. Una classe di test JUnit contiene un metodo [setUp] che viene eseguito prima di qualsiasi altro metodo. È lì che verrà creato il singleton [ArticlesDaoPlainJdbc].

Se si segue la soluzione che prevede il passaggio delle informazioni di configurazione tramite il costruttore, si otterrà la seguente classe di test:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
public class TestArticlesPlainJdbc extends TestCase {
    // verifica la classe di accesso agli articoli ArticlesDaoPlainJdbc
     // la fonte dati è definita in sprintest

     // un'istanza della classe sottoposta a test
    private IArticlesDao articlesDao;

    protected void setUp() throws Exception{
        // recupera un'istanza di accesso ai dati
        articlesDao =
            (IArticlesDao) new ArticlesDaoPlainJdbc("org.firebirdsql.jdbc.FBDriver",
                "jdbc:firebirdsql:localhost/3050:d:/databases/dbarticles.gdb","someone","somepassword");
    }

La classe chiamante [TestArticlesPlainJdbc] deve conoscere le quattro informazioni necessarie per l’inizializzazione del singleton [ArticlesDaoPlainJdbc] da costruire.

Se si segue la soluzione che prevede il passaggio delle informazioni di configurazione tramite file di configurazione, si potrebbe ottenere la seguente classe di test utilizzando il file Spring descritto in precedenza.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
public class TestSpringArticlesPlainJdbc extends TestCase {
    // testa la classe di accesso agli articoli ArticlesDaoJdbc
     // la fonte dati è definita in sprintest

     // un'istanza della classe sottoposta a test
    private IArticlesDao articlesDao;

    protected void setUp() throws Exception {
      // recupera un'istanza di accesso ai dati
      articlesDao = (IArticlesDao) (new XmlBeanFactory(new ClassPathResource(
          "springArticlesPlainJdbc.xml"))).getBean("articlesDao");
    }

In questo caso, la classe di chiamata [TestSpringArticlesPlainJdbc] non deve conoscere le informazioni necessarie per l’inizializzazione del singleton da creare. Deve semplicemente conoscere:

  1. [springArticlesPlainJdbc.xml]: il nome del file di configurazione Spring descritto in precedenza
  2. [articlesDao]: il nome del singleton da creare

Una modifica al file di configurazione, al di fuori di queste due entità, non ha alcun impatto sul codice Java. Questo metodo di configurazione degli oggetti di un’applicazione è molto flessibile. Per configurarsi, l’applicazione deve conoscere solo due cose:

  • il nome del file Spring che contiene la definizione dei singleton da creare
  • i nomi di questi singleton, che servono al codice Java per ottenere un riferimento agli oggetti a cui sono stati associati tramite il file di configurazione

2.2. Iniezione di dipendenze e inversione di controllo

Introduciamo ora il concetto di iniezione di dipendenze (Dependency Injection) utilizzato da Spring per configurare le applicazioni. Si utilizza anche il termine inversione di controllo (IoC, Inversion of Control). Consideriamo la creazione del singleton [ArticlesManagerWithDataBase] del livello business della nostra applicazione:

Per accedere ai dati del SGBD, il livello business deve utilizzare i servizi di un oggetto che implementi l’interfaccia [IArticlesDao], ad esempio un oggetto di tipo [ArticlesDaoPlainJdbc]. Il codice della classe [ArticlesManagerWithDataBase] potrebbe essere simile al seguente:

public class ArticlesManagerWithDataBase implements IArticlesManager {

     // un'istanza di accesso ai dati
    private IArticlesDao articlesDao;
 ....
    public ArticlesManagerWithDataBase (String driverClassName, String url, String user, String pwd, ...) {
        ... 
         // creazione del servizio di accesso ai dati
        articlesDao =(IArticlesDao)new ArticlesDaoPlainJdbc(driverClassName,url,user,pwd);
    ...
    }

    public ... doSomething(...){
        ...
    }
}

La classe [ArticlesDaoPlainJdbc] dovrebbe implementare qui un'interfaccia [IArticlesDao]:

public class ArticlesDaoPlainJdbc implements IArticlesDao {...}

Per creare il singleton di tipo [IArticlesDao] necessario al funzionamento della classe, il costruttore di quest'ultima utilizza esplicitamente il nome della classe di implementazione dell'interfaccia [IArticlesDao]:

articlesDao =(IArticlesDao) new ArticlesDaoPlainJdbc(...);

Si ha quindi una dipendenza rigida nel codice dal nome della classe. Se la classe di implementazione dell’interfaccia [IArticlesDao] dovesse cambiare, il codice del costruttore precedente dovrebbe essere modificato. Si hanno le seguenti relazioni tra gli oggetti:

La classe [ArticlesManagerWithDataBase] prende autonomamente l'iniziativa di creare l'oggetto [ArticlesDaoPlainJdbc] di cui ha bisogno. Tornando al termine "inversione di controllo", si dirà che è lei ad avere il "controllo" per creare l'oggetto di cui ha bisogno.

Se dovessimo scrivere una classe di test JUnit per la classe [ArticlesManagerWithDataBase], potremmo ottenere qualcosa di simile a quanto segue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
public class TestArticlesManagerWithDataBase extends TestCase {
    // un'istanza della classe di business sottoposta a test
    private IArticlesManager articlesManager;

    protected void setUp() throws Exception {
        // crea un'istanza della classe di business sottoposta a test
        articlesManager =
            (IArticlesManager) new ArticlesManagerWithDataBase("org.firebirdsql.jdbc.FBDriver",
                "jdbc:firebirdsql:localhost/3050:d:/databases/dbarticles.gdb","someone","somepassword");
    }

La classe di test crea un’istanza della classe di business [ArticlesManagerWithDataBase] che, a sua volta, nel proprio costruttore, crea un’istanza della classe di accesso ai dati [ArticlesDaoPlainJdbc].

La soluzione con Spring eliminerà la necessità per la classe di business [ArticlesManagerWithDataBase] di conoscere il nome [ArticlesDaoPlainJdbc] della classe di accesso ai dati di cui ha bisogno. Ciò consentirà di modificarla senza intervenire sul codice Java della classe di business. Spring consentirà di creare contemporaneamente i due singleton, quello del livello di accesso ai dati e quello del livello business. Il file di configurazione di Spring definirà un nuovo bean:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans SYSTEM "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
     <!-- la classe di accesso ai dati -->
    <bean id="articlesDao" class="istia.st.articles.dao.ArticlesDaoPlainJdbc">
        <constructor-arg index="0">
            <value>org.firebirdsql.jdbc.FBDriver</value>
        </constructor-arg>
        <constructor-arg index="1">
            <value>jdbc:firebirdsql:localhost/3050:d:/databases/dbarticles.gdb</value>
        </constructor-arg>
        <constructor-arg index="2">
            <value>someone</value>
        </constructor-arg>
        <constructor-arg index="3">
            <value>somepassword</value>
        </constructor-arg>
    </bean>
    <bean id="articlesManager" class="istia.st.articles.domain.ArticlesManagerWithDataBase">
        <property name="articlesDao">
            <ref bean="articlesDao"/>
        </property>
    </bean>
</beans>

La novità risiede nel bean che definisce il singleton della classe di business da creare:

    <bean id="articlesManager" class="istia.st.articles.domain.ArticlesManagerWithDataBase">
        <property name="articlesDao">
            <ref bean="articlesDao"/>
        </property>
    </bean>
  1. è definita la classe che implementa il bean [articlesManager]: [ArticlesManagerWithDataBase]
  2. il campo [articlesDao] del bean riceve un valore tramite il tag <property name="articlesDao">. Si tratta del campo definito nella classe [ArticlesManagerWithDataBase]: 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
public class ArticlesManagerWithDataBase implements IArticlesManager {

  // interfaccia di accesso ai dati
  private IArticlesDao articlesDao;

  public IArticlesDao getArticlesDao() {
    return articlesDao;
  }

  public void setArticlesDao(IArticlesDao articlesDao) {
    this.articlesDao = articlesDao;
  }

Affinché il campo [articlesDao] possa essere inizializzato da Spring tramite il tag <property>, è necessario che il campo rispetti lo standard JavaBean e che esista un metodo [setArticlesDao] per inizializzare il campo [articlesDao]. Si noti il nome del metodo, derivato in modo ben preciso dal nome del campo. Parallelmente, esiste spesso un metodo [get...] per ottenere il valore del campo. In questo caso, si tratta del metodo [getArticlesDao]. In questa nuova versione, la classe [ArticlesManagerWithDataBase] non ha più un costruttore. Non ne ha più bisogno.

  • Il valore che verrà assegnato al campo [articlesDao] da Spring è quello del bean [articlesDao] definito nel suo file di configurazione: 
    <bean id="articlesManager" class="istia.st.articles.domain.ArticlesManagerWithDataBase">
        <property name="articlesDao">
            <ref bean="articlesDao"/>
        </property>
    </bean>

    <bean id="articlesDao" class="istia.st.articles.dao.ArticlesDaoPlainJdbc">
        <constructor-arg index="0">
    .............
    </bean>
  • quando Spring creerà il singleton [ArticlesManagerWithDataBase], dovrà creare anche il singleton [ArticlesDaoPlainJdbc]:
    • Spring creerà un grafico delle dipendenze dei bean e noterà che il bean [articlesManager] dipende dal bean [articlesDao]
    • creerà il bean [articlesDao], ovvero un oggetto di tipo [ArticlesDaoPlainJdbc]
    • quindi creerà il bean [articlesManager] di tipo [ArticlesManagerWithDataBase]

Immaginiamo ora un test JUnit per la classe [ArticlesManagerWithDataBase]. Potrebbe essere simile al seguente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public class TestSpringArticlesManagerWithDataBase extends TestCase {
    // testa la classe di business [ArticlesManagerWithDataBase]

    // un'istanza della classe di business testata
    private IArticlesManager articlesManager;

    protected void setUp() throws Exception {
      // recupera un'istanza di accesso ai dati
      articlesManager = (IArticlesManager) (new XmlBeanFactory(new ClassPathResource(
          "springArticlesManagerWithDataBase.xml"))).getBean("articlesManager");
    }

Seguiamo il processo di creazione dei due singleton definiti nel file Spring denominato [springArticlesManagerWithDataBase.xml].

  • Il metodo [setUp] sopra riportato richiede un riferimento al bean denominato [articlesManager]
  • Spring consulta il proprio file di configurazione e individua il bean [articlesManager]. Se è già stato creato, si limita a restituire un riferimento all’oggetto (singleton); in caso contrario, lo crea.
  • Spring rileva la dipendenza del bean [articlesManager] dal bean [articlesDao]. Crea quindi il singleton [articlesDao] di tipo [ArticlesDaoPlainJdbc] se quest’ultimo non è già stato creato (singleton).
  • Crea il singleton [articlesManager] di tipo [ArticlesManagerWithDataBase]

Questo meccanismo potrebbe essere schematizzato come segue:

Ricordiamo la struttura della classe [ArticlesManagerWithDataBase]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
public class ArticlesManagerWithDataBase implements IArticlesManager {

  // interfaccia di accesso ai dati
  private IArticlesDao articlesDao;

  public IArticlesDao getArticlesDao() {
    return articlesDao;
  }

  public void setArticlesDao(IArticlesDao articlesDao) {
    this.articlesDao = articlesDao;
  }

Al termine della creazione dei singleton da parte di Spring, si ottiene un oggetto di tipo [ArticlesManagerWithDataBase] il cui campo [articlesDao] è stato inizializzato senza che esso ne conosca il modo. Si dice che sia stata iniettata una dipendenza nell’oggetto [ArticlesManagerWithDataBase]. Si dice anche che si sia invertito il controllo: non è più l’oggetto [ArticlesManagerWithDataBase] a prendere l’iniziativa di creare autonomamente l’oggetto che implementa l’interfaccia [IArticlesDao] di cui ha bisogno, ma è l’applicazione al livello più alto (al momento dell’inizializzazione) che si occupa di creare tutti gli oggetti di cui ha bisogno, gestendo le dipendenze tra di essi.

Il vantaggio principale della configurazione del singleton [ArticlesManagerWithDataBase] tramite un file Spring è che ora è possibile modificare la classe di implementazione corrispondente al campo [articlesDao] della classe [ArticlesManagerWithDataBase] senza che il codice di quest’ultima venga modificato. È sufficiente modificare il nome della classe nella definizione del bean [articlesDao] nel file Spring:

    <bean id="articlesDao" class="istia.st.articles.dao.ArticlesDaoPlainJdbc">
...
    </bean>

diventerà, ad esempio:

    <bean id="articlesDao" class="istia.st.articles.dao.ArticlesDaoIbatisSqlMap">
...
    </bean>

Il bean [ArticlesManagerWithDataBase] funzionerà con questa nuova classe di accesso ai dati, senza nemmeno rendersene conto.

2.3. Spring IoC nella pratica

2.3.1. Esempio 1

Consideriamo la seguente classe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package istia.st.springioc.domain;

public class Personne {
  private String nom;
  private int age;

   // visualizzazione Persona
  public String toString() {
    return "nom=[" + this.nom + "], age=[" + this.age + "]";
  }

   // init-close
  public void init() {
    System.out.println("init personne [" + this.toString() + "]");
  }

  public void close() {
    System.out.println("destroy personne [" + this.toString() + "]");
  }

   // getters-setters
  public int getAge() {
    return age;
  }

  public void setAge(int age) {
    this.age = age;
  }

  public String getNom() {
    return nom;
  }

  public void setNom(String nom) {
    this.nom = nom;
  }
}

La classe presenta:

  • due campi privati nome ed età
  • i metodi di lettura (get) e scrittura (set) di questi due campi
  • un metodo toString per recuperare il valore dell’oggetto [Personne] sotto forma di stringa di caratteri
  • un metodo init che verrà chiamato da Spring al momento della creazione dell'oggetto, un metodo close che verrà chiamato al momento della distruzione dell'oggetto

Per creare oggetti di tipo [Personne], utilizzeremo il seguente file Spring:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
    "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="personne1" class="istia.st.springioc.domain.Personne" 
        init-method="init" destroy-method="close">
        <property name="nom">
            <value>Simon</value>
        </property>
        <property name="age">
            <value>40</value>
        </property>
    </bean>
    <bean id="personne2" class="istia.st.springioc.domain.Personne" 
        init-method="init" destroy-method="close">
        <property name="nom">
            <value>Brigitte</value>
        </property>
        <property name="age">
            <value>20</value>
        </property>
    </bean>
</beans>

Questo file si chiamerà config.xml.

  • Definisce due bean con chiavi rispettivamente "persona1" e "persona2" di tipo [Personne]
  • Inizializza i campi [nom, age] di ciascuna persona
  • definisce i metodi da chiamare durante la creazione iniziale dell’oggetto [init-method] e durante la distruzione dell’oggetto [destroy-method]

Per i nostri test, utilizzeremo un'unica classe di test JUnit alla quale aggiungeremo successivamente dei metodi. La prima versione di questa classe sarà la seguente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
package istia.st.springioc.tests;

import istia.st.springioc.domain.Personne;
import org.springframework.beans.factory.ListableBeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;
import junit.framework.TestCase;

public class Tests extends TestCase {

   // fabbrica di bean
  private ListableBeanFactory bf;

   // test di inizializzazione
  public void setUp() {
    bf = new XmlBeanFactory(new ClassPathResource("config.xml"));
  }

  public void test1() {
    // recupero dei bean tramite la loro chiave [Personne] dal file Spring
    Personne personne1 = (Personne) bf.getBean("personne1");
    System.out.println("personne1=" + personne1.toString());
    Personne personne2 = (Personne) bf.getBean("personne2");
    System.out.println("personne2=" + personne2.toString());
    personne2 = (Personne) bf.getBean("personne2");
    System.out.println("personne2=" + personne2.toString());
  }
}

Commenti:

  • per ottenere i bean definiti nel file [config.xml], utilizziamo un oggetto di tipo [ListableBeanFactory]. Esistono altri tipi di oggetti che consentono di accedere ai bean. L’oggetto [ListableBeanFactory] viene ottenuto nel metodo [setUp] della classe di test e memorizzato in una variabile privata. Sarà così disponibile per tutti i metodi di test.
  • Il file [config.xml] verrà inserito nel [ClassPath] dell’applicazione, c.a.d, in una delle directory esplorate dalla macchina virtuale Java quando cerca una classe a cui fa riferimento l’applicazione. L'oggetto [ClassPathResource] serve a cercare una risorsa nel [ClassPath] di un'applicazione, in questo caso il file [config.xml].
  • Spring può utilizzare file di configurazione in vari formati. L’oggetto [XmlBeanFactory] consente di analizzare un file di configurazione in formato XML.
  • L'elaborazione di un file Spring restituisce un oggetto di tipo [ListableBeanFactory], in questo caso l'oggetto bf. Con questo oggetto, un bean identificato dalla chiave C si ottiene tramite bf.getBean(C).
  • Il metodo [test1] richiede e visualizza il valore dei bean con chiave "persona1" e "persona2".

La struttura del progetto Eclipse della nostra applicazione è la seguente:

Image

Commenti:

  • la cartella [src] contiene i codici sorgente. I codici compilati andranno in una cartella [bin] non rappresentata qui.
  • Il file [config.xml] si trova nella directory principale della cartella [src]. Durante la compilazione del progetto, il file viene automaticamente copiato nella cartella [bin], che fa parte della cartella [ClassPath] dell'applicazione. È lì che viene cercato dall'oggetto [ClassPathResource].
  • La cartella [lib] contiene tre librerie Java necessarie all’applicazione:
      • commons-logging.jar e spring-core.jar per le classi Spring
      • junit.jar per le classi JUnit
  • anche la cartella [lib] fa parte del [ClassPath] dell’applicazione

L'esecuzione del metodo [test1] del test JUnit fornisce i seguenti risultati:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
18 sept. 2004 11:28:53 org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [config.xml]
18 sept. 2004 11:28:53 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'personne1'
init personne [nom=[Simon], age=[40]]
personne1=nom=[Simon], age=[40]
18 sept. 2004 11:28:53 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'personne2'
init personne [nom=[Brigitte], age=[20]]
personne2=nom=[Brigitte], age=[20]
personne2=nom=[Brigitte], age=[20]

Commenti:

  • Spring registra una serie di eventi tramite la libreria [commons-logging.jar]. Questi log ci consentono di comprendere meglio il funzionamento di Spring.
  • Il file [config.xml] è stato caricato e successivamente utilizzato
  • L'operazione* 
Personne personne1 = (Personne) bf.getBean("personne1");

ha forzato la creazione del bean [personne1]. Si può vedere il log di Spring a questo proposito. Poiché nella definizione del bean [personne1] era stato scritto [init-method="init"], è stato eseguito il metodo [init] dell’oggetto [Personne] creato. Viene visualizzato il messaggio corrispondente.

  • L'operazione 
System.out.println("personne1=" + personne1.toString());

ha visualizzato il valore dell'oggetto [Personne] creato.

  • Lo stesso fenomeno si ripete per il bean chiave [personne2].
  • L'ultima operazione 
    personne2 = (Personne) bf.getBean("personne2");
    System.out.println("personne2=" + personne2.toString());

non ha provocato la creazione di un nuovo oggetto di tipo [Personne]. Se così fosse stato, sarebbe stato visualizzato il metodo [init], cosa che qui non avviene. È il principio del singleton. Spring, per impostazione predefinita, crea una sola istanza dei bean presenti nel proprio file di configurazione. Si tratta di un servizio di riferimento agli oggetti. Se gli viene richiesto il riferimento a un oggetto non ancora creato, lo crea e ne restituisce un riferimento. Se l’oggetto è già stato creato, Spring si limita a fornirne un riferimento.

  • Si può notare che non c’è traccia del metodo [close] dell’oggetto [Personne], mentre nella definizione dei bean era stato scritto [destroy-method=close]. È possibile che questo metodo venga eseguito solo quando la memoria occupata dall’oggetto viene recuperata dal garbage collector. Nel momento in cui ciò avviene, l’applicazione è già terminata e la scrittura sullo schermo non ha alcun effetto. Da verificare.

Avendo ormai acquisito le basi per una configurazione Spring, d’ora in poi saremo un po’ più rapidi nelle nostre spiegazioni.

2.3.2. Esempio 2

Consideriamo la seguente nuova classe [Voiture]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
package istia.st.springioc.domain;

public class Voiture {
  private String marque;
  private String type;
  private Personne propriétaire;

   // costruttori

  public Voiture() {
  }

  public Voiture(String marque, String type, Personne propriétaire) {
    this.marque = marque;
    this.type = type;
    this.propriétaire = propriétaire;
  }

   // toString
  public String toString() {
    return "Voiture : marque=[" + this.marque + "] type=[" + this.type
        + "] propriétaire=[" + this.propriétaire + "]";
  }

     // getter-setter
  public String getMarque() {
    return marque;
  }

  public void setMarque(String marque) {
    this.marque = marque;
  }

  public Personne getPropriétaire() {
    return propriétaire;
  }

  public void setPropriétaire(Personne propriétaire) {
    this.propriétaire = propriétaire;
  }

  public String getType() {
    return type;
  }

  public void setType(String type) {
    this.type = type;
  }

   // init-close
  public void init() {
    System.out.println("init voiture [" + this.toString() + "]");
  }

  public void close() {
    System.out.println("destroy voiture [" + this.toString() + "]");
  }

}

La classe presenta:

  • tre campi privati: tipo, marca e proprietario. Questi campi possono essere inizializzati e letti tramite i metodi pubblici get e set dei bean. Possono inoltre essere inizializzati utilizzando il costruttore Auto(String, String, Persona). La classe dispone anche di un costruttore senza argomenti per conformarsi allo standard JavaBean.
  • un metodo toString per recuperare il valore dell’oggetto [Voiture] sotto forma di stringa
  • un metodo `init` che verrà chiamato da Spring subito dopo la creazione dell’oggetto, un metodo `close` che verrà chiamato al momento della distruzione dell’oggetto

Per creare oggetti di tipo [Voiture], utilizzeremo il seguente file Spring [config.xml]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
    "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="personne1" class="istia.st.springioc.domain.Personne" 
        init-method="init" destroy-method="close">
        <property name="nom">
            <value>Simon</value>
        </property>
        <property name="age">
            <value>40</value>
        </property>
    </bean>
    <bean id="personne2" class="istia.st.springioc.domain.Personne" 
        init-method="init" destroy-method="close">
        <property name="nom">
            <value>Brigitte</value>
        </property>
        <property name="age">
            <value>20</value>
        </property>
    </bean>
    <bean id="voiture1" class="istia.st.springioc.domain.Voiture" 
        init-method="init" destroy-method="close">
        <constructor-arg index="0">
            <value>Peugeot</value>
        </constructor-arg>
        <constructor-arg index="1">
            <value>307</value>
        </constructor-arg>
        <constructor-arg index="2">
            <ref bean="personne2"></ref>
        </constructor-arg>
    </bean>
</beans>

Questo file aggiunge alle definizioni precedenti un bean con chiave "voiture1" di tipo [Voiture]. Per inizializzare questo bean, si sarebbe potuto scrivere:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
    <bean id="voiture1" class="istia.st.springioc.domain.Voiture" 
        init-method="init" destroy-method="close">
        <property name="marque">
            <value>Peugeot</value>
        </property>
        <property name="type">
            <value>307</value>
        </property>
        <property name="propriétaire">
            <ref bean="personne2"/>
        </property>
    </bean>

Anziché optare per questo metodo già illustrato, in questo caso abbiamo scelto di utilizzare il costruttore Voiture(String, String, Personne) della classe. Inoltre, il bean [voiture1] definisce il metodo da chiamare durante la creazione iniziale dell’oggetto [init-method] e quello da chiamare durante la distruzione dell’oggetto [destroy-method].

Per i nostri test, utilizzeremo la classe di test JUnit già presentata, aggiungendovi il seguente metodo [test2]:

1
2
3
4
5
  public void test2() {
     // recupero del bean [voiture1]
    Voiture Voiture1 = (Voiture) bf.getBean("voiture1");
    System.out.println("Voiture1=" + Voiture1.toString());
  }

Il metodo [test2] recupera il bean [voiture1] e lo visualizza.

La struttura del progetto Eclipse rimane quella del test precedente. L'esecuzione del metodo [test2] del test JUnit fornisce i seguenti risultati:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
18 sept. 2004 14:56:10 org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [config.xml]
18 sept. 2004 14:56:10 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'voiture1'
18 sept. 2004 14:56:10 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'personne2'
init personne [nom=[Brigitte], age=[20]]
18 sept. 2004 14:56:10 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory autowireConstructor
INFO: Bean 'voiture1' instantiated via constructor [public istia.st.springioc.domain.Voiture(java.lang.String,java.lang.String,istia.st.springioc.domain.Personne)]
init voiture [Voiture : marque=[Peugeot] type=[307] propriétaire=[nom=[Brigitte], age=[20]]]
Voiture1=Voiture : marque=[Peugeot] type=[307] propriétaire=[nom=[Brigitte], age=[20]]

Commenti:

  1. il metodo [test2] richiede un riferimento al bean [voiture1]
  2. riga 4: Spring avvia la creazione del bean [voiture1] poiché tale bean non è ancora stato creato (singleton)
  3. riga 6: poiché il bean [voiture1] fa riferimento al bean [personne2], quest'ultimo viene a sua volta creato
  4. riga 7: il bean [personne2] è stato creato. Viene quindi eseguito il suo metodo [init].
  5. riga 9: Spring indica che utilizzerà un costruttore per creare il bean [voiture1]
  6. riga 10: il bean [voiture1] è stato creato. Viene quindi eseguito il suo metodo [init].
  7. riga 11: il metodo [test2] visualizza il valore del bean [voiture1]

2.3.3. Esempio 3

Introduciamo la seguente nuova classe [GroupePersonnes]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
package istia.st.springioc.domain;

import java.util.Map;

public class GroupePersonnes {
  private Personne[] membres;
  private Map groupesDeTravail;

   // getter - setter
  public Personne[] getMembres() {
    return membres;
  }

  public void setMembres(Personne[] membres) {
    this.membres = membres;
  }

  public Map getGroupesDeTravail() {
    return groupesDeTravail;
  }

  public void setGroupesDeTravail(Map groupesDeTravail) {
    this.groupesDeTravail = groupesDeTravail;
  }

   // visualizzazione
  public String toString() {
    String liste = "membres : ";
    for (int i = 0; i < this.membres.length; i++) {
      liste += "[" + this.membres[i].toString() + "]";
    }
    return liste + ", groupes de travail = " + this.groupesDeTravail.toString();
  }

   // init-close
  public void init() {
    System.out.println("init GroupePersonnes [" + this.toString() + "]");
  }

  public void close() {
    System.out.println("destroy GroupePersonnes [" + this.toString() + "]");
  }
}

I suoi due membri privati sono:

membri: un array di persone appartenenti al gruppo

groupesDeTravail: un dizionario che associa una persona a un gruppo di lavoro

Si noti che la classe [GroupePersonnes] non definisce un costruttore senza argomenti per seguire lo standard JavaBean. Ricordiamo che, in assenza di qualsiasi costruttore, esiste un costruttore "predefinito" che è il costruttore senza argomenti e che non esegue alcuna operazione.

In questa sede si intende mostrare come Spring consenta di inizializzare oggetti complessi, quali quelli dotati di campi di tipo array o dizionario. Si aggiunge un nuovo bean al precedente file Spring [config.xml]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
    <bean id="groupe1" class="istia.st.springioc.domain.GroupePersonnes" 
        init-method="init" destroy-method="close">
        <property name="membres">
            <list>
                <ref bean="personne1"/>
                <ref bean="personne2"/>
            </list>
        </property>
        <property name="groupesDeTravail">
            <map>
                <entry key="Brigitte">
                    <value>Marketing</value>
                </entry>
                <entry key="Simon">
                    <value>Ressources humaines</value>
                </entry>
            </map>
        </property>
    </bean>
  1. Il tag <list> consente di inizializzare un campo di tipo array o che implementa l’interfaccia List con valori diversi.
  2. Il tag <map> consente di fare la stessa cosa con un campo che implementa l’interfaccia Map

Per i nostri test, utilizzeremo la classe di test JUnit già presentata, aggiungendovi il seguente metodo [test3]:

1
2
3
4
5
  public void test3() {
    // recupero del bean [groupe1]
    GroupePersonnes groupe1 = (GroupePersonnes) bf.getBean("groupe1");
    System.out.println("groupe1=" + groupe1.toString());
  }

Il metodo [test3] recupera il bean [groupe1] e lo visualizza.

La struttura del progetto Eclipse rimane quella del test precedente. L'esecuzione del metodo [test3] del test JUnit fornisce i seguenti risultati:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
18 sept. 2004 15:51:45 org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [config.xml]
18 sept. 2004 15:51:45 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'groupe1'
18 sept. 2004 15:51:45 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'personne1'
init personne [nom=[Simon], age=[40]]
18 sept. 2004 15:51:45 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'personne2'
init personne [nom=[Brigitte], age=[20]]
init GroupePersonnes [membres : [nom=[Simon], age=[40]][nom=[Brigitte], age=[20]], groupes de travail = {Brigitte=Marketing, Simon=Ressources humaines}]
groupe1=membres : [nom=[Simon], age=[40]][nom=[Brigitte], age=[20]], groupes de travail = {Brigitte=Marketing, Simon=Ressources humaines}

Commenti:

  • il metodo [test3] richiede un riferimento al bean [groupe1]
  • riga 4: Spring avvia la creazione di questo bean
  • poiché il bean [groupe1] fa riferimento ai bean [personne1] e [personne2], questi due bean vengono creati (righe 6 e 9) e il loro metodo init viene eseguito (righe 7 e 10)
  • riga 11: il bean [groupe1] è stato creato. Il suo metodo [init] viene ora eseguito.
  • riga 12: visualizzazione richiesta dal metodo [test3].

2.4. Spring per configurare applicazioni web a tre livelli

2.4.1. Architettura generale dell’applicazione

Si desidera realizzare un’applicazione a tre livelli con la seguente struttura:

  • i tre livelli saranno resi indipendenti grazie all’utilizzo di interfacce Java
  • l'integrazione dei tre livelli sarà realizzata da Spring
  • Verranno creati pacchetti separati per ciascuno dei tre livelli, denominati Control, Domain e Dao. Un pacchetto aggiuntivo conterrà le applicazioni di test.

La struttura dell’applicazione in Eclipse potrebbe essere la seguente:

Image

2.4.2. Il livello DAO di accesso ai dati

Il livello DAO implementerà la seguente interfaccia:

package istia.st.demo.dao;

public interface IDao1 {
  public int doSometingInDaoLayer(int a, int b);
}
  • Scrivere due classi Dao1Impl1 e Dao1Impl2 che implementino l'interfaccia IDao1. Il metodo Dao1Impl1. doSomethingInDaoLayer restituirà a+b, mentre il metodo Dao1Impl2. doSomethingInDaoLayer restituirà a-b.
  • scrivere una classe di test JUnit che verifichi le due classi precedenti

2.4.3. Il livello business

Il livello business implementerà la seguente interfaccia:

package istia.st.demo.domain;

public interface IDomain1 {
  public int doSomethingInDomainLayer(int a, int b);
}
  • Scrivere due classi, Domain1Impl1 e Domain1Impl2, che implementino l'interfaccia IDomain1. Queste classi avranno un costruttore che accetta come parametro un oggetto di tipo IDao1. Il metodo Domain1Impl1.doSomethingInDomainLayer incrementerà a e b di un'unità, quindi passerà questi due parametri al metodo doSomethingInDaoLayer dell'oggetto di tipo IDao1 ricevuto. Il metodo Domain1Impl2.doSomethingInDomainLayer, invece, decrementerà a e b di un'unità prima di eseguire la stessa operazione.
  • Scrivere una classe di test JUnit che verifichi le due classi precedenti

2.4.4. Il livello dell'interfaccia utente

Il livello dell'interfaccia utente implementerà la seguente interfaccia:

package istia.st.demo.control;

public interface IControl1 {
  public int doSometingInControlLayer(int a, int b);
}
  • Scrivere due classi, Control1Impl1 e Control1Impl2, che implementino l'interfaccia IControl1. Queste classi avranno un costruttore che accetta un parametro di tipo IDomain1. Il metodo Control1Impl1.doSomethingInControlLayer incrementerà a e b di un'unità, quindi passerà questi due parametri al metodo doSomethingInDomainLayer dell'oggetto di tipo IDomain1 ricevuto. Il metodo Control11Impl2.doSomethingInControlLayer, invece, decrementerà a e b di un'unità prima di eseguire la stessa operazione.
  • Scrivere una classe di test JUnit che verifichi le due classi precedenti

2.4.5. Integrazione con Spring

  • Scrivere un file di configurazione Spring che stabilisca quali classi dovrà utilizzare ciascuno dei tre livelli precedenti
  • Scrivere una classe di test JUnit che utilizzi diverse configurazioni Spring, al fine di evidenziare la flessibilità dell'applicazione scritta
  • Scrivere un'applicazione autonoma (metodo main) che passi due parametri all'interfaccia IControl1 e visualizzi il risultato restituito dall'interfaccia.

2.4.6. Una soluzione

2.4.6.1. Il progetto Eclipse

Image

Gli archivi della cartella [lib] sono stati aggiunti al [ClassPath] del progetto.

2.4.6.2. Il pacchetto [istia.st.demo.dao]

L'interfaccia:

1
2
3
4
5
6
7
8
9
package istia.st.demo.dao;

/**
 * @author ST-ISTIA
 *  
 */
public interface IDao1 {
  public int doSometingInDaoLayer(int a, int b);
}

Una prima classe di implementazione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
package istia.st.demo.dao;

/**
 * @author ST-ISTIA
 *  
 */
public class Dao1Impl1 implements IDao1 {

     // si esegue un'operazione nel livello [dao]
  public int doSometingInDaoLayer(int a, int b) {
    return a+b;
  }

}

Una seconda classe di implementazione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
package istia.st.demo.dao;

/**
 * @author ST-ISTIA
 *
 */
public class Dao1Impl2 implements IDao1 {

     // si esegue un'operazione nel livello [dao]
  public int doSometingInDaoLayer(int a, int b) {
    return a-b;
  }
}

2.4.6.3. Il pacchetto [istia.st.demo.domain]

L'interfaccia:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
package istia.st.demo.domain;

/**
 * @author ST-ISTIA
 *  
 */
public interface IDomain1 {

     // si fa qualcosa nel livello [domain]
  public int doSomethingInDomainLayer(int a, int b);
}

Una prima classe di implementazione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package istia.st.demo.domain;

import istia.st.demo.dao.IDao1;

/**
 * @author ST-ISTIA
 *  
 */
public class Domain1Impl1 implements IDomain1 {

     // il servizio di accesso al livello [dao]
  private IDao1 dao1;

  public Domain1Impl1() {
     // costruttore senza argomenti
  }

     // memorizza il servizio di accesso al livello [dao]
  public Domain1Impl1(IDao1 dao1) {
    this.dao1 = dao1;
  }

     // si esegue un'operazione nel livello [domain]
  public int doSomethingInDomainLayer(int a, int b) {
    a++;
    b++;
    return dao1.doSometingInDaoLayer(a, b);
  }
}

Una seconda classe di implementazione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package istia.st.demo.domain;

import istia.st.demo.dao.IDao1;

/**
 * @author ST-ISTIA
 *  
 */
public class Domain1Impl2 implements IDomain1 {

     // il servizio di accesso al livello [dao]
  private IDao1 dao1;

  public Domain1Impl2() {
     // costruttore senza argomenti
  }

     // memorizza il servizio di accesso al livello [dao]
  public Domain1Impl2(IDao1 dao1) {
    this.dao1 = dao1;
  }

     // si esegue un'operazione nel livello [domain]
  public int doSomethingInDomainLayer(int a, int b) {
    a--;
    b--;
    return dao1.doSometingInDaoLayer(a, b);
  }
}

2.4.6.4. Il pacchetto [istia.st.demo.control]

L'interfaccia

1
2
3
4
5
6
7
8
9
package istia.st.demo.control;

/**
 * @author ST-ISTIA
 *  
 */
public interface IControl1 {
  public int doSometingInControlLayer(int a, int b);
}

Una prima classe di implementazione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package istia.st.demo.control;

import istia.st.demo.domain.IDomain1;

/**
 * @author ST-ISTIA
 *  
 */
public class Control1Impl1 implements IControl1 {
   // classe di business nel livello [domain]
    private IDomain1 domain1;

  public Control1Impl1() {
     // costruttore senza argomenti
  }

     // memorizzazione del servizio di accesso al livello [domain]
  public Control1Impl1(IDomain1 domain1) {
    this.domain1 = domain1;
  }

     // si esegue un'operazione
  public int doSometingInControlLayer(int a, int b) {
    a++;
    b++;
    return domain1.doSomethingInDomainLayer(a, b);
  }

}

Una seconda classe di implementazione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
package istia.st.demo.control;

import istia.st.demo.domain.IDomain1;

/**
 * @author ST-ISTIA
 *  
 */
public class Control1Impl2 implements IControl1 {

     // la classe di accesso al livello [domain]
    private IDomain1 domain1;

  public Control1Impl2() {
     // costruttore senza argomenti
  }

     // memorizza la classe di accesso al livello [domain]
  public Control1Impl2(IDomain1 domain1) {
    this.domain1 = domain1;
  }

     // si esegue un'operazione
  public int doSometingInControlLayer(int a, int b) {
    a--;
    b--;
    return domain1.doSomethingInDomainLayer(a, b);
  }

}

2.4.6.5. I file di configurazione [Spring]

Un primo [springMainTest1.xml]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans SYSTEM "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
     <!-- la classe DAO -->
    <bean id="dao" class="istia.st.demo.dao.Dao1Impl1">
    </bean>
     <!-- la classe di business -->
    <bean id="domain" class="istia.st.demo.domain.Domain1Impl1">
        <constructor-arg index="0">
            <ref bean="dao"/>
        </constructor-arg>
    </bean>
     <!-- la classe di controllo -->
    <bean id="control" class="istia.st.demo.control.Control1Impl1">
        <constructor-arg index="0">
            <ref bean="domain"/>
        </constructor-arg>
    </bean>
</beans>

Un secondo [springMainTest2.xml]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans SYSTEM "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
     <!-- la classe DAO -->
    <bean id="dao" class="istia.st.demo.dao.Dao1Impl2">
    </bean>
     <!-- la classe di business -->
    <bean id="domain" class="istia.st.demo.domain.Domain1Impl2">
        <constructor-arg index="0">
            <ref bean="dao"/>
        </constructor-arg>
    </bean>
     <!-- la classe di controllo -->
    <bean id="control" class="istia.st.demo.control.Control1Impl2">
        <constructor-arg index="0">
            <ref bean="domain"/>
        </constructor-arg>
    </bean>
</beans>

2.4.6.6. Il pacchetto di test [istia.st.demo.tests]

Un test di tipo [main]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package istia.st.demo.tests;

import istia.st.demo.control.IControl1;

import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;

/**
 * @author ST-ISTIA
 *  
 */
public class MainTest1 {
  public static void main(String[] arguments) {
     // si recupera un'implementazione dell'interfaccia IControl1
    IControl1 control = (IControl1) (new XmlBeanFactory(new ClassPathResource(
        "springMainTest1.xml"))).getBean("control");
     // si utilizza la classe
    int a = 10, b = 20;
    int res = control.doSometingInControlLayer(a, b);
     // si visualizza il risultato
    System.out.println("control(" + a + "," + b + ")=" + res);
  }
}

I risultati ottenuti sulla console Eclipse:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
11 mars 2005 11:25:14 org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [springMainTest1.xml]
11 mars 2005 11:25:14 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'control'
11 mars 2005 11:25:14 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'domain'
11 mars 2005 11:25:14 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'dao'
11 mars 2005 11:25:14 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory autowireConstructor
INFO: Bean 'domain' instantiated via constructor [public istia.st.demo.domain.Domain1Impl1(istia.st.demo.dao.IDao1)]
11 mars 2005 11:25:14 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory autowireConstructor
INFO: Bean 'control' instantiated via constructor [public istia.st.demo.control.Control1Impl1(istia.st.demo.domain.IDomain1)]
control(10,20)=34

Un altro test che utilizza il secondo file di configurazione [Spring]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
package istia.st.demo.tests;

import istia.st.demo.control.IControl1;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;

/**
 * @author ST-ISTIA
 *  
 */
public class MainTest2 {
  public static void main(String[] arguments) {
     // si recupera un'implementazione dell'interfaccia IControl1
    IControl1 control = (IControl1) (new XmlBeanFactory(new ClassPathResource(
        "springMainTest2.xml"))).getBean("control");
     // si utilizza la classe
    int a = 10, b = 20;
    int res = control.doSometingInControlLayer(a, b);
     // si visualizza il risultato
    System.out.println("control(" + a + "," + b + ")=" + res);
  }
}

Risultati ottenuti sulla console di Eclipse:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
11 mars 2005 11:28:52 org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [springMainTest2.xml]
11 mars 2005 11:28:52 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'control'
11 mars 2005 11:28:52 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'domain'
11 mars 2005 11:28:52 org.springframework.beans.factory.support.AbstractBeanFactory getBean
INFO: Creating shared instance of singleton bean 'dao'
11 mars 2005 11:28:52 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory autowireConstructor
INFO: Bean 'domain' instantiated via constructor [public istia.st.demo.domain.Domain1Impl2(istia.st.demo.dao.IDao1)]
11 mars 2005 11:28:52 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory autowireConstructor
INFO: Bean 'control' instantiated via constructor [public istia.st.demo.control.Control1Impl2(istia.st.demo.domain.IDomain1)]
control(10,20)=-10

Infine, un test Junit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package istia.st.demo.tests;

import istia.st.demo.control.IControl1;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;
import junit.framework.TestCase;

/**
 * @author ST-ISTIA
 *  
 */
public class JunitTest2Control1 extends TestCase {
  public void testControl1() {
     // si recupera un'implementazione dell'interfaccia IControl1
    IControl1 control1 = (IControl1) (new XmlBeanFactory(new ClassPathResource(
        "springMainTest1.xml"))).getBean("control");
     // si utilizza la classe
    int a1 = 10, b1 = 20;
    int res1 = control1.doSometingInControlLayer(a1, b1);
    assertEquals(34, res1);
     // si recupera un'altra implementazione dell'interfaccia IControl1
    IControl1 control2 = (IControl1) (new XmlBeanFactory(new ClassPathResource(
        "springMainTest2.xml"))).getBean("control");
     // si utilizza la classe
    int a2 = 10, b2 = 20;
    int res2 = control2.doSometingInControlLayer(a2, b2);
    assertEquals(-10, res2);
  }
}

2.5. Conclusion

Il framework Spring offre una reale flessibilità sia nell'architettura delle applicazioni che nella loro configurazione. Abbiamo utilizzato il concetto IoC, uno dei due pilastri di Spring. L’altro pilastro è AOP (Aspect Oriented Programming), che non abbiamo presentato. Consente di aggiungere, tramite configurazione, un “comportamento” a un metodo di classe senza modificarne il codice. Schematicamente, AOP permette di filtrare le chiamate a determinati metodi:

  • il filtro può essere eseguito prima o dopo il metodo M di destinazione, oppure in entrambi i casi.
  • Il metodo M ignora l’esistenza di questi filtri. Questi ultimi sono definiti nel file di configurazione di Spring.
  • Il codice del metodo M non viene modificato. I filtri sono classi Java da implementare. Spring fornisce filtri predefiniti, in particolare per gestire le transazioni di SGBD.
  • I filtri sono bean e, in quanto tali, sono definiti nel file di configurazione di Spring come bean.

Un filtro comune è il filtro transazionale. Prendiamo un metodo M del livello business che esegue due operazioni indissociabili sui dati (unità di lavoro). Esso richiama due metodi M1 e M2 del livello DAO per eseguire queste due operazioni.

Poiché si trova nel livello business, il metodo M non tiene conto del supporto di questi dati. Ad esempio, non deve di ipotizzare che i dati si trovino in un SGBD e che sia necessario inserire le due chiamate ai metodi M1 e M2 all’interno di una transazione di SGBD. Spetta al livello DAO occuparsi di questi dettagli. Una soluzione al problema precedente consiste quindi nel creare un metodo nel livello DAO che a sua volta chiami i metodi M1 e M2, chiamate che includerebbe in una transazione di SGBD.

La soluzione di filtraggio AOP è più flessibile. Consentirà di definire un filtro che, prima della chiamata a M, avvierà una transazione e, dopo la chiamata, eseguirà un commit o un rollback a seconda dei casi.

Questo approccio presenta diversi vantaggi:

  • una volta definito il filtro, può essere applicato a più metodi, ad esempio a tutti quelli che richiedono una transazione
  • i metodi così filtrati non devono essere riscritti
  • poiché i filtri da utilizzare sono definiti tramite configurazione, è possibile modificarli

Oltre ai concetti IoC e AOP, Spring offre numerose classi di supporto per le applicazioni a tre livelli:

  • per JDBC, SqlMap (iBatis), Hibernate, JDO (Java Data Object) nel livello DAO
  • per il modello MVC nel livello Interfaccia utente

Per ulteriori informazioni: http://www.springframework.org.

https://stahe.github.io
Questo tutorial scritto da Serge Tahé è reso disponibile al pubblico secondo i termini della Creative Commons Attribuzione – Non commerciale – Condividi allo stesso modo 3.0 Unported.