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:

140 maggio
, anno 2009

Il programmatore e le sue API

XIV parte: Il business service layer con 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

XIV parte: Il business service layer con Spring

Alfredo Larotonda

Alfredo Larotonda

  • Questo articolo parla di: Architetture dei sistemi, DataBase & elaborazione dei dati, Frameworks & Tools, Programmazione & Linguaggi

Concludiamo l‘analisi del business service layer illustrando come Spring possa interagire con lo strato di persistenza.

Introduzione

Con il presente articolo concludiamo la trattazione del business service layer implementato con il framework Spring approfondendo l’interazione dello stesso con lo strato di persistenza. Abbiamo già parlato dei benefici nell’uso di Spring come framework di implementazione dello strato di business e abbiamo visto come sia possibile costruire in modo molto semplice una architettura applicativa che preveda uno strato di business esposto allo strato di presentation esclusivamente mediante interfacce.
Analogamente è possibile integrare con la stessa filosofia lo strato di persistenza, che nella discussione che segue supporremo realizzato con Hibernate in coerenza a quanto fino ad ora visto nella serie. Vedremo come Spring metta a disposizione tutti gli strumenti necessari per realizzare questa integrazione in modo coerente ai principi del pattern IoC e in modo come sempre estremamente semplice per lo sviluppatore. Scrivere codice di persistenza utilizzando le librerie di supporto di Spring semplifica notevolmente il compito dello sviluppatore e conduce alla scrittura di codice estremamente conciso, privo di istruzioni ridondanti e semplice da manutenere.

Spring e il layer di persistenza

Spring fornisce classi di supporto che consentono di semplificare la scrittura del codice di accesso ai dati e di sfruttare le caratteristiche del container IoC indipendentemente dalla soluzione scelta per implementare lo strato di persistenza. Sia che si utilizzi per l’implementazione il puro e semplice JDBC che un framework ORM come Hibernate, Spring mette a disposizione classi di supporto e classi template che semplificano di gran lunga la scrittura dei DAO. Sfruttando le caratteristiche del container IoC inoltre tutte le dipendenze tra gli oggetti di business e i DAO vengono settate dal container e configurate all’esterno del codice senza la necessità di codice applicativo dedicato.
Nel nostro caso la scelta per l’implementazione dello strato di persistenza è caduta su Hibernate, l’ormai arcinoto framework ORM, ma la trattazione sarebbe assolutamente analoga nel caso si scegliesse una diversa soluzione implementativa.
Spring mette a disposizione classi DAO astratte per le varie tecnologie di accesso ai dati, come JDBC e Hibernate, ma anche ad esempio JDO, che possono essere estese dalle classi DAO del progetto che possono così sfruttare una serie di metodi standard che facilitano la scrittura del codice di persistenza.

Nel caso di Hibernate questa classe è la HibernateDAOSupport che diventa la superclasse di tutti i DAO della nostra applicazione. A questa classe deve essere fornito un riferimento a una SessionFactory operazione che ovviamente viene assolta dal container IoC mediante la definizione di un bean di tipo

org.springframework.orm.hibernate.LocalSessionFactoryBean

A sua volta la SessionFactory, che ci consentirà di acquisire sessioni per interagire con Hibernate, deve avere un riferimento a un data source per l’accesso al database dell’applicazione. Facendo l’ipotesi di utilizzare un JNDI data source, Spring mette a disposizione la classe

org.springframework.jndi.JndiObjectFactoryBean

Nell’esempio che segue è mostrato un tipico file di configurazione del container di Spring che mostra come tutti gli oggetti che hanno a che fare con lo strato di persistenza e le loro dipendenze vengono definiti completamente dal container stesso. Viene definito un bean dataSource il cui riferimento è iniettato nel bean sessionFactory che come proprietà prevede quanto in genere configurato nel file di proprietà di Hibernate. Tra queste vi è la lista dei file per il mapping tra oggetti persistenti e tabelle del database.


"http://www.springframework.org/dtd/spring-beans.dtd">
          
    <!—Definzione datasource -->
        class="org.springframework.jndi.JndiObjectFactoryBean">
        
            java:comp/env/jdbc/dbmoka
        
    
    
        class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
        
            
        
    
        
            it/mokabyte/api/User.hbm.xml
        
    
    
        
            
            net.sf.hibernate.dialect.HSQLDialect
            
        
    

A questo punto una volta creati i vari oggetti necessari all’interazione con Hibernate, non resta che iniettare le dipendenze nei DAO e negli oggetti di business che utilizzano i DAO stessi. Dovrebbe quindi risultare finalmente chiaro quanto si era visto nel precedente articolo [4] riguardo la definizione del DAO e dell’oggetto di business di esempio:

    
        
    


    
        

L’oggetto del business service layer, il bean “service”, ha visibilità esclusivamente dell’interfaccia DAO , la cui implementazione è definita nel file di configurazione di Spring mentre nel DAO viene iniettata la dipendenza alla sessionFactory.

Supponendo di realizzare un DAO per accedere ad una ipotetica tabella utenti denominata USER, questo avrebbe una struttura simile:

package it.mokabyte.api.dao.hibernate;
// imports...
public class HibernateDAOImpl extends HibernateDaoSupport implements DAOInterface
{
    public List getUsers()
    {
        return getHibernateTemplate().find("from USER");
    }
    public User getUser(Long id) {
        return (User) getHibernateTemplate().get(User.class, id);
    }
}

Si è ipotizzato che il nostro DAO implementi una interfaccia che preveda un metodo per reperire tutti gli utenti dalla nostra tabella (getUsers()) e un metodo per reperire i dati di un singolo utente a partire da un codice identificativo univoco dello stesso (getUser(Long id)).

Come si vede il DAO implementa i metodi dell’interfaccia ed estende la classe astratta di supporto che fornisce il metodo getHibernateTemplate() che restituisce una istanza di HibernateTemplate una classe helper che facilita la scrittura del codice di persistenza e wrappa le eccezioni di Hibernate nella gerarchia standard di eccezioni di Spring, indipendenti dalla tecnologia di implementazione dello strato di persistenza.

È facile notare come la struttura del DAO, già di per se’ semplificata con il solo uso di Hibernate, diventi ancora più semplice con l’utilizzo delle classi di supporto di Spring che nascondono tutta la gestione degli oggetti di Hibernate.
Come già detto il business service layer è assolutamente agnostico rispetto all’implementazione dello strato di persistenza in quanto ha un riferimento esclusivamente all’interfaccia DAO.
La classe dello strato di business avrà quindi la seguente struttura:

package it.mokabyte.api.service.impl;
//imports...
public class ServiceInterfaceImpl implements ServiceInterface
{
    private DAOInterface dao;
    public void setDAOInterface(DAOInterface dao) {
        this.dao = dao;
    }
    public List getUsers() {
        return dao.getUsers();
    }
    public User getUser(String userId) {
        User user = dao.getUser(Long.valueOf(userId));
        return user;
    }
}

 

Si noti il metodo setter che serve al container per iniettare la dipendenza al DAO e come nella classe non vi sia alcune riferimento alla tecnologia di implementazione dello strato di persistenza che è esposto allo strato di business solo mediante un’interfaccia.

Ciò rende gli oggetti di business realmente riusabili e indipendenti dallo strato di persistenza e conduce al risultato che avevamo annunciato nell’introduzione dell’articolo.
L’esempio mostrato è ovviamente una semplificazione in quanto non sempre esiste una relazione uno a uno tra un oggetto di business e un DAO, ma tutto quanto visto resta assolutamente valido anche in scenari molto più complessi.

Conclusioni

Nel presente articolo abbiamo mostrato come sia possibile utilizzare le classi di supporto di Spring per realizzare uno strato di business service layer realmente indipendente dalla tecnologia implementativa dello strato di persistenza. Non si è parlato della gestione delle transazioni in quanto è un argomento che meriterebbe una serie di articoli dedicati, soprattutto per ciò che riguarda la gestione dichiarativa che sfrutta le caratteristiche di Spring AOP, il modulo di Spring per la programmazione ad aspetti. Per chi fosse interessato a un approfondimento in tal senso si rimanda alla documentazione del framework [5]. Lo scopo degli articoli dedicati a Spring era piuttosto quello di mostrare come, utilizzando le caratteristiche del framework, sia possibile realizzare architetturalmente una applicazione con uno strato di business veramente riusabile e modulare che è visibile all’esterno solo mediante interfacce e che vede gli strati sottostanti allo stesso modo esclusivamente tramite interfacce in accordo ai migliori principi architetturali che prevedono un basso accoppiamento tra i layer applicativi. Tutto ciò può essere ottenuto senza grosso sforzo, con coerenza architetturale tra i vari componenti e con notevole semplicità da un punto di vista realizzativo, proprio come è stato illustrato.

Riferimenti

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

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

[3] Rod Johnson, “Introduction to the Spring Framework 2.5”, TheServerSide.com, Ottobre 2007

[4] Alfredo Larotonda, “Il programmatore e le sue API – XIII Parte: Approfondiamo Spring”, Mokabyte 138, Marzo 2009

[5] Rod Johnson et al., “The Spring Framework. Reference Documentation – Chapter 9: Transaction Management”

 

 

 

 

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...

Java 6: le novità Enterprise

I parte: la direzione intrapresa

Algoritmi Genetici

IX parte: Implementazione in Java

Algoritmi di Garbage Collection

III parte: Ottimizzazione e monitoraggio del Garbage Collector

Strumenti di build e test con Groovy

I parte: Gant, il build secondo Groovy

Web Beans

III parte: Deployment types e stereotipi

Java Authentication and Authorization Service

III parte: Autorizzazione 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

XIII parte: Approfondiamo 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

VIII parte: Il 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

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