Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

138 marzo
, anno 2009

Il programmatore e le sue API

XIII parte: Approfondiamo Spring

Alfredo Larotonda

Alfredo Larotonda

Alfredo Larotonda, laureato in Ingegneria Elettronica, lavora da diversi anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo di applicazioni web per il mercato finanziario e industriale, si occupa ora in particolare di aspetti architetturali per progetti rivolti al mercato della pubblica amministrazione. È Sun Certified Enterprise Architect (SCEA) e ha inoltre conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.

MokaByte

Il programmatore e le sue API

XIII parte: Approfondiamo Spring

Alfredo Larotonda

Alfredo Larotonda

  • Questo articolo parla di: Architetture dei sistemi, Frameworks & Tools, Java, Programmazione & Linguaggi

Implementare il business service layer con Spring è un‘ottima scelta per la flessibilità e la modularità che il framework conferisce alla nostra applicazione ma anche per la sua semplicità d‘uso. Iniziamo a vedere come questo possa essere messo in pratica.

Introduzione

Nel precedente articolo abbiamo iniziato la trattazione del business service layer ed abbiamo visto come Spring possa essere oggi una delle migliori scelte per la sua implementazione. I concetti che sono alla base di Spring sono stati introdotti nel precedente articolo. Ora vedremo come si può implementare nella pratica lo strato di business sfruttando le caratteristiche del framework. È bene sottolineare che la trattazione è assolutamente indipendente dalla tecnologia con cui alla fine si deciderà di implementare il layer di presentation, con Jakarta Struts, con JSF o con lo stesso Spring. Lo scopo è quello di illustrare come si possa realizzare uno strato di servizi di business assolutamente riusabili in qualsiasi contesto applicativo. Questo obiettivo è facilmente raggiungibile con Spring visto che per sua natura consente la scrittura di applicazioni estremamente modulari e di componenti realmente riusabili.

Dal momento che abbiamo già trattato il persistence layer ed abbiamo già discusso di Hibernate si farà l’assunto che il layer di servizi utilizzi a sua volta le interfacce esposte da un layer di persistenza implementato con Hibernate.

L’architettura dell’applicazione

Come si era già detto, uno dei principi fondamentali per l’implementazione di uno strato di business realmente riusabile è quello di realizzare un insieme di “servizi” che espongono le loro funzionalità al client mediante interfacce ben definite. Nella nostra discussione il client è lo strato di presentazione. Il componenti del layer di presentation, quelli che svolgono la funzione di controller in particolare, avranno esclusivamente un riferimento a una interfaccia. Ciò significa che il presentation layer potrà rimanere del tutto invariato al modificarsi dell’implementazione dei metodi di business definiti nell’interfaccia stessa. Questo principio fondamentale di una buona programmazione a oggetti ha come presupposto che in qualche modo i componenti dell’applicazione riescano ad acquisire i riferimenti agli oggetti di implementazione delle interfacce di business. Ciò significa che da qualche parte è necessario andare a reperire i riferimenti alle classi di implementazione delle interfacce di business. A tale scopo si usa spesso un ServiceLocator ossia una classe che implementa il pattern ServiceLocator e che consente di accentrare in un unico componente tutte le operazioni di lookup necessarie a reperire i componenti desiderati. Sebbene il ServiceLocator sia un pattern che conferisce una struttura più solida e manutenibile alla propria applicazione, esso costituisce pur sempre un aggravio di operatività e di scrittura di codice per una operazione assolutamente ripetitiva e a scarso valore aggiunto. Con Spring tutto ciò non è necessario in quanto, come già detto nel precedente articolo parlando del principio dell’Inversion Of control, è Spring che si occupa di iniettare le dipendenze tra le classi della nostra applicazione secondo una logica opposta a quella in cui sono le classi stesse ad andare a reperirsi i riferimenti agli oggetti di cui hanno bisogno.

L’architettura applicativa di una applicazione che utilizza Spring per l’implementazione del proprio strato di business può essere quindi molto semplificata rispetto a quelle tradizionali.

In pratica, i componenti di controllo del web layer, le Action di Struts o i managed bean di JSF, avranno un riferimento a una interfaccia esposta dal layer di business. Il riferimento al bean di implementazione dell’interfaccia sarà iniettato nel componente di presentation layer dal container IoC di Spring senza che il primo debba andare a compiere alcuna operazione. Ciò consente innanzitutto di scrivere meno codice ma rende soprattutto i layer ben distinti e poco accoppiati, caratteristica fondamentale per la corretta realizzazione di un’applicazione.

Nella nostra architettura avremo quindi una interfaccia di business (che chiameremo ServiceInterface) che espone al presentation layer i metodi di business che saranno implementati da una classe (un comune POJO, che chiameremo ServiceInterfaceImpl). Le dipendenze tra i vari oggetti sono tutte iniettate dal container IoC di Spring.

In Figura 1 è rappresentato il diagramma delle classi dell’architettura descritta contenente per semplicità solo gli elementi essenziali alla comprensione di quanto detto. Come si vede, il componente di presentation layer “conosce” esclusivamente l’interfaccia di business e non la sua implementazione. Stessa cosa accade tra la classe di implementazione dell’interfaccia di business e lo strato di persistenza. I layer sono ben distinti e non vi è la necessità da parte di nessuno dei componenti dell’architettura di andarsi a reperire riferimenti agli oggetti degli altri layer: a questo, come vedremo, pensa Spring.

Figura 1 – Architettura applicativa del business layer con Spring.

A parte i dettagli implementativi, la cosa importante da notare è come ogni layer sia visibile all’altro solo mediante interfacce, allo scopo di evitare pericolose dipendenze tra layer distinti che potrebbero condurre a seri problemi nel caso in cui uno dei layer venisse pesantemente modificato.

La struttura descritta è la più semplice possibile da realizzarsi con Spring, ma il fatto che sia semplice non significa che non sia efficiente e ben fatta.

A volte è facile trovare in applicazioni costruite con Spring vere e proprie classi di tipo Business Delegate che espongono metodi di business allo strato di presentation utilizzando al loro interno le interfacce dei servizi del layer di business. Questa seconda possibilità introduce un ulteriore livello di astrazione tra presentation layer e business layer e può essere presa in considerazione in situazioni nelle quali il livello di business è così articolato che si preferisce mascherarne la complessità con l’utilizzo di BusinessDelegate. In realtà si può osservare che una ServiceInterface assolve di per se’ ai compiti di BusinessDelegate quindi in realtà tra le due architetture non c’è una sostanziale differenza; oltre a ciò spesso quello che succede è che si viene a creare un rapporto uno-a-uno tra classi business delegate e interfacce di business il che vanifica totalmente il ruolo dei BusinessDelegate stessi.

Inoltre è bene ricordare che Spring ha in se’ i meccanismi che consentono di iniettare le dipendenze nei componenti di presentation layer più diffusi, come le Action di Struts o i managed bean di JSF, semplicemente configurando opportunamente l’applicazione. L’introduzione di una classe di BusinessDelegate costringe invece a dover effettuare nel codice dello stesso delle operazioni di acquisizione dei bean dal contesto di Spring, magari mediante l’uso di ServiceLocator. Ciò, a mio parere, contraddice il concetto stesso di IoC ed è quindi qualcosa di poco pulito da un punto di vista architetturale.

La configurazione del contesto di Spring

Dopo aver dato un’occhiata all’architettura dell’applicazione, vediamo come sia possibile realizzare tutto ciò con Spring soffermandoci solo sugli elementi di interesse per la nostra discussione. La configurazione di una applicazione che realizzi lo schema presentato è quanto di più semplice possa esistere.

Innanzitutto è necessario inizializzare il contesto di Spring; lo facciamo inserendo nel web.xml dell’applicazione l’opportuno listener:

    org.springframework.web.context.ContextLoaderListener

A questo punto è necessario configurare opportunamente il contesto di Spring definendo queste famose dipendenze tra gli oggetti di cui abbiamo tanto parlato. È possibile farlo andando a scrivere un file XML che per una applicazione web solitamente si chiama applicationContext.xml e si trova nella cartella /WEB-INF dell’applicazione (nel web.xml è possibile configurare un nome e un percorso alternativo per questo file).

Il file di configurazione di Spring è molto semplice in quanto consiste quasi esclusivamente nella definizione di una serie di bean e delle loro dipendenze. Vedremo il file nel suo insieme quando completeremo la discussione; per ora ci basta analizzare le due sezioni qui di sotto estrapolate allo scopo di vedere come vengano definiti i bean di implementazione del DAO e dell’interfaccia di business e come in quest’ultimo venga “iniettata” la dipendenza al DAO stesso realizzando quanto descritto in Figura 1.

    
        
    


    
        

È il container di Spring che istanzia i bean in questione e che assegna alla proprietà dao della classe it.mokabyte.api.service.impl.ServiceInterfaceImpl un riferimento alla classe it.mokabyte.api.dao.hibernate.HibernateDAOImpl.

Le classi in questione sono semplici POJO che implementano le interfacce definite e sono riportate qui di seguito nella loro struttura base.

Ecco l’interfaccia e il bean di implementazione del Service

package it.mokabyte.api.service;

          public interface ServiceInterface
{
    //business service methods
}
 
package it.mokabyte.api.service.impl;

          import it.mokabyte.api.dao.DAOInterface;
import it.mokabyte.api.service.ServiceInterface;

          public class ServiceInterfaceImpl
    implements ServiceInterface
{
    private dao DAOInterface;
   
    public UserServiceImpl()
    {
    }
    public void setDao(DAOInterface dao)
    {
        this.dao = dao;
    }
   
    public DAOInterface get Dao ()
    {
        return dao;
    }
}

Ed ecco l’interfaccia e il bean di implementazione del DAO

package it.mokabyte.api.dao;

          public interface DAOInterface
{
    //dao methods
    ............
}

          package it.mokabyte.api.dao.hibernate;

          import org.springframework.orm.hibernate3.support.HibernateDaoSupport;

          public class HibernateDAOImpl
    extends HibernateDaoSupport
    implements DAOInterface
{
    //dao implementation methods
}

Quello che manca per completare la struttura di Figura 1 è capire come iniettare il riferimento al bean di implementazione dell’interfaccia di business dentro al componente di presentation layer.

In [6] avevamo già mostrato come farlo in maniera molto semplice utilizzando JSF per lo strato di presentation. Senza addentrarci in una discussione che esula dallo scopo dell’articolo, ma solo a scopo di completezza, in questo caso supponiamo che per lo strato di presentation si sia usato Struts e che si voglia iniettare il riferimento alla classe di implementazione dell’interfaccia di business in una Action.

A tale scopo occorre inserire nello struts-config.xml il plugin di Spring che consente a Struts di avere un riferimento al contesto di Spring:

                value="/WEB-INF/applicationContext.xml"/>

Inoltre per ogni Action che usa Spring va ridefinito il mapping utilizzando la classe org.springframework.web.struts.DelegatingActionProxy come segue:

        type="org.springframework.web.struts.DelegatingActionProxy"
        name="form" scope="request" parameter="method">
    

Infine va definita la classe Action come bean nel contesto di Spring e va iniettata in essa il riferimento al bean di implementazione dell’interfaccia di business:

    
        

La struttura di Figura 1 è così realizzata: ogni layer vede il layer adiacente esclusivamente tramite interfacce e tutti i riferimenti alle classi di implementazione delle interfacce stesse vengono forniti ai diversi componenti dal container di Spring senza la necessità di scrittura di una sola riga di codice.

Conclusioni

Nel presente articolo abbiamo visto come sia possibile strutturare un’applicazione web utilizzando Spring per l’implementazione dello strato di business. Nel prossimo articolo completeremo la discussione sul business layer vedendo più nel dettaglio anche la configurazione dello strato di persistenza e l’interazione con Hibernate. Quello che si voleva già da ora trasmettere è come sia estremamente semplice costruire con Spring uno strato di servizi riusabili da esporre mediante interfacce a un qualsivoglia strato di presentation senza che ciò aggiunga alcuna complessità alla nostra applicazione.

Riferimenti

[1] Rod Johnson, “Expert one-on-one. J2EE Design and Development”, 2002, Wrox Press

[2] Rod Johnson – Juergen Holler, “Expert one-on-one. J2EE Development without EJB”, 2004, Wrox Press

[3] Rod Johnson, “Introduction to the Spring Framework 2.5”, Ottobre 2007, The ServerSide.Com

[4] Giovanni Puliti, “Il programmatore e le sue API – VI parte: L’architettura del sistema”, MokaByte 132, Settembre 2008

[5] Giovanni Puliti, “Il programmatore e le sue API – VII parte: Ancora sull’uso dei pattern nell’architettura”, Mokabyte 133, Ottobre 2008

[6] Alfredo Larotonda “JSF in azione – IV parte: Integrazione”, Mokabyte 125, Gennaio 2008

 

 

 

Facebook
Twitter
LinkedIn
Alfredo Larotonda

Alfredo Larotonda

Alfredo Larotonda, laureato in Ingegneria Elettronica, lavora da diversi anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo di applicazioni web per il mercato finanziario e industriale, si occupa ora in particolare di aspetti architetturali per progetti rivolti al mercato della pubblica amministrazione. È Sun Certified Enterprise Architect (SCEA) e ha inoltre conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.

Alfredo Larotonda

Alfredo Larotonda

Alfredo Larotonda, laureato in Ingegneria Elettronica, lavora da diversi anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo di applicazioni web per il mercato finanziario e industriale, si occupa ora in particolare di aspetti architetturali per progetti rivolti al mercato della pubblica amministrazione. È Sun Certified Enterprise Architect (SCEA) e ha inoltre conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.
Tutti gli articoli
Nello stesso numero
Loading...

Web Beans

I parte: Introduzione e specifiche

Algoritmi di Garbage Collection

I parte: panoramica e concetti di base

Java Authentication and Authorization Service

I parte: Introduzione alla sicurezza e a JAAS

Nella stessa serie
Loading...

Il programmatore e le sue API

XIX parte: Introduzione al test delle applicazioni enterprise

Il programmatore e le sue API

XX parte: realizzare la GUI web con GWT

Il programmatore e le sue API

XVIII parte: Sviluppare l‘interfaccia web con tecnologie RIA

Il programmatore e le sue API

XVII parte: Il logging corretto

Il programmatore e le sue Api

XVI parte: La gestione delle eccezioni nelle applicazioni enterprise

Il programmatore e le sue api

XV parte: Integriamo il layer di presentazione realizzato con JSF

Il programmatore e le sue API

XIV parte: Il business service layer con Spring

Il programmatore e le sue API

XII parte: Il business service layer con Spring

Il programmatore e le sue Api

XI parte: Considerazioni finali sulla persistenza

Il programmatore e le sue API

X parte: Ultime considerazioni sulla persistenza con Hibernate

Il programmatore e le sue API

IX parte: Ancora sul design della persistenza con Hibernate

Il programmatore e le sue api

VII parte: Ancora sull‘uso dei pattern nella architettura

Il programmatore e le sue API

VIII parte: Il design della persistenza con Hibernate

Il programmatore e le sue api

VI parte: L‘architettura del sistema

Il programmatore e le sue api

V parte: ancora sulla persistenza, due relazioni particolari

Il programmatore e le sue api

IV parte: Il design della persistenza

Il programmatore e le sue api

III parte: Si inizia a definire il datamodel

Il programmatore e le sue api

II parte: Impostare la fase di analisi

Il programmatore e le sue api

I parte: Lo startup di progetto

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte