JUG – Ancona Italy Spring Framework Andrea Del Bene Jug Marche

● 40% il container: abbiamo un container che si occupa dei nostri oggetti e abbiamo visto come funziona. L'utilità di Spring: ● 60% le classi del framework: ci sono tante classi di utilità in Spring. Spesso ci aiuteranno nei compiti più faticosi. ● Nel nostro file di contesto troveremo diverse istanze di queste classi di utilità per esigenze “spiccie”. ● Anche se usiamo tante classi di Spring il framework rimane poco invasivo e saremo sempre liberi di usare le soluzioni che più ci piacciono. Il team di Spring spende TANTE energie per rendere facile l'integrazione con framework di terze parti! Spring: da dove inizio? Che ci faccio?

● L'accesso al database è la prima (onnipresente!) operazione che Spring ci facilita con le sue classi. <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> ${database.driverClassName} ${database.url} ${database.user} ${database.password} ● Vediamo da cosa sono i dollari e le parentesi graffe... ● Il bean dataSource richiede le informazioni indispensabiliper connettersi con JDBC, ma... Tutto inizia dai dati...

● I file di properties sono file testuali con coppie chiave/ valore all'interno di essi. Sono molto utili per raccogliere tutti quei parametri che cambiano da pc a pc (lingua, formato data, ecc...). ● Ad esempio i parametri di connessione al database... database.url=jdbc:mysql://localhost:3306/jug4tenda database.driverClassName=com.mysql.jdbc.Driver database.hibernateDialect=org.hibernate.dialect.MySQLDialect database.user=root database.password= ● I file di properties sono file testuali con coppie chiave/ valore all'interno di essi. Sono molto utili per raccogliere tutti quei parametri che cambiano da pc a pc (lingua, formato data, ecc...). Il file di properties

<bean id="propertyPlaceholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> classpath:springConfigFiles/dataBase.properties classpath:messages.properties true Il file di properties (2) La classe PropertyPlaceholderConfigurer rende visibili nel file di context i file di properties specificati nell'attributo location. Come si vede è possibile specificarne un numero arbitrario. Il prefisso classpath: serve ovviamente per cercare i file partendo dalla cartella principale di esecuzione. I valori delle properties si usano nel file di contesto con la notazione ${...}

Spring dispone di un vasto set di classi di integrazione con librerie di terze parti. Hibernate è ovviamente incluso tra queste. Integrazione con Hibernate

La session è la classe principale di interazione con Hibernate... Integrazione con Hibernate 2

● E' tutto dichiarativo: i passi necessari (connessione del database, creazione/ chiusura della sessione, ecc...) a lavorare con hibernate sono espressi in maniera dichiarativa (xml) e non sono cablati nel codice. - Anche la transazione è dichiarativa, come vedremo (AOP + proxy)... ● Meno codice ripetitivo: Spring gestisce la sessione Hibernate per noi. ● Niente più TCFTC (try/catch-finally-try/catch): il passaggio da eccezioni checked ad unchecked ci permette di gestire le eccezioni dove vogliamo. ● Per capire questo vantaqggio ci vuole un pò di esperienza... Spring + hibernate: vantaggi

● II patter Proxy si basa essenzialmente sulle interfacce. Un client usa un oggetto vedendolo come implementazione di un'interfaccia. ● Ci possono essere tante implementazioni della stessa interfaccia, per il client non cambia nulla. ● Al posto dell'implementazione dell'interfaccia al client diamo il proxy, che è visto sempre come un'interfaccia e "gira" le invocazioni dei metodi ad un'implementazione specifica... ● Esattamente come il proxy Internet che si “finge” un pc connesso reindirizzando e smistando il traffico su più pc. Pattern proxy

● Anche questo pattern si basa sulle interfacce. Concettualmente è molto semplice. ● L'oggetto che si occupa della persistenza delle entità deve implementare un'interfaccia che raccoglie tutti i metodi che agiscono sulle entità (save, (delete, ecc...) Pattern DAO

Pattern DAO 2 ● Nel progetto Jug4Tenda c'è il package org.jugancona.jug4tenda. domainManagers.interfaces dove si trovano delle interfacce dal nome Manager Es: OspiteManager, AccoglienzaManager, ecc... ● Queste interfacce sono implementate da altrettanti DAO che operano su Hibernate, presenti nel package org.jugancona.jug4tenda.domainManagers Nulla vieta di fare altre DAO che operano su file o con un altro ORM e così via ● Le implementazioni di questi DAO per Hibernate hanno nome Hib. Es: HibOspiteManager. ● Vantaggio: una sola interfaccia per il data manager, tante implementazioni (per Hibernate, per salvare su file, ecc...)

● L'AOP è un nuovo paradigma di programmazione complementare all'OOP. ● Permette di isolare aspetti comuni a varie componenti di un'applicazione (login, sicurezza,ecc...) applicandoli in maniera dichiarativa a determinati punti d'esecuzione (detti pointcuts). Tali punti di esecuzione corrispondono a metodi di determinate interfacce o oggetti presenti in un'applicazione. Possiamo quindi concentrare in un unica classe il codice usato e ripetuto in vari metodi per fare, ad esempio, controlli sulla sicurezza. ● Mediante AOP possiamo gestire il ciclo di vita di un oggetto e l'esecuzionedei suoi metodi controllando che prima della loro esecuzione siano rispettatedeterminate precondizioni impostate dal progettista. ● In questo modo possiamo controllare la disponibilità e lo stato delle risorse necessarie all'esecuzione, modificando a runtime il comportamento della nostra applicazione. Un novo approccio: l' Aspect- Oriented Programming

I pointcut sono punti dell'esecuzione del programma a cui applicare gli aspetti. Il modo più semplice e funzionale per definire i pointcut è di applicarli ai metodi di un oggetto che implementa un' interfaccia. Gli aspetti possono poi essere applicati prima dell'esecuzione di un determinato metodo o dopo. L'AOP definisce tre tipi di aspetti che : 1)Before advice: è invocato prima dell'esecuzione del metodo a cui è stato agganciato. 2)After advice: è invocato dopo l'esecuzione del metodo a cui è stato agganciato. 3)Around advice: è il tipo di aspetto più potente dei tre. Consente di modificare a piacimento il flusso elaborativo del metodo invocato e può addirittura non invocare quest' ultimo. Fondamenti di AOP

Esempio: In figura viene riassunto l'effetto delle prime due tipologie di aspetto sull'esecuzione del metodo foo() generico. Esempi di aspetti.

● Il problema è semplice: ogni volta che salvo un etità devo vedere se i dati rispettano le regole di validazione. ● Nel progetto Jug4Tenda: ogni volta che salvo un'accoglienza devo verificare che il periodo di accoglienza non superi i 10 gg (se non prolungata), che la data di inizio non sia successiva a quella di fine,ecc... ● Soluzione classica: nel manager delle accoglienze, nel metodo saveAccoglienza metto dei controlli (tanti blocchi if..) ● Funziona...ma quanti limiti! ● Mi piacerebbe concentrare le logiche di validazione in una classe a parte, per meglio gestirle. Soluzione classica: nel manager delle accoglienze, nel metodo saveAccoglienza metto dei controlli (tanti blocchi if..) ● Il manager obbedisce al pattern DAO. Per ogni implemtazione dell'interfaccia manager dovrei ripetere il codice di validazione (replicazione di codice --> antipattern) ! Esempio di AOP: la validazione.

Soluzione AOP: intercepting dei metodi ● Posso usare un before advice sul metodo di interfaccia saveAccoglienza e qui fare la validazione. ● La validazione è così concentrata in una classe apposita, riutilizzabile e applicabile in maniera dichiarativa alle implementazioni dell'interfaccia DAO. ● L'ultimo passo è usare una classe proxy che "simuli" il DAO a cui applicare l'advice.

● La classe BeforSaveAccoglienza è la classe che si occupa fisicamente di fare la validazione che ci apprestiamo a salvare. Pointcut e classe validazione ● La classe RegexpMethodPointcutAdvisor definisce il pointcut, ossia a quali metodi si applica BeforSaveAccoglienza: tutti quelli che inziano con save. Noi avremo solo saveAccoglienza.

La classe proxy ● La classe proxy specifica l'interfaccia che andrà a "simulare" (AccoglienzaManager) e carica gli Interceptor (ossia i pointcut) che vanno applicati all'istanza target (accoglienzaManager)

La classe target ● La classe target è il DAO vero e proprio per Hibernate. Ricordiamoci che implementa l'interfaccia AccoglienzaManager. ● Nel bean accoglienzaManagerProxy avevamo detto tramite l'attributo target che le chiamte al proxy devono essere "girate" a HibAccoglienzaManager

La classe client ● Ora la classe client (OspiteController) che vuole usare AccoglienzaManager riceverà il riferimento all'oggetto proxy. ● Il campo accoglienzaManager di OspiteController (il client) si aspetta un'implementazione di interfaccia AccoglienzaManager e non è minimamente consapevole di usare un proxy!

E questo...?

● TransactionInterceptor è un'altro aspetto che applichiamo al proxy! Politiche di transazione ● Il blocco esclusivo delle tabelle si ha solo in scrittura.

Link utili ● Spring framework ( è il sito ufficiale dove scaricare Spring e aggiornarsi sulle ultime novità del monso Spring. Blog Interface21 ( è il blog dei creatori di Spring. Si possono trovare idee e spunti di utilizzo del framework. ● An Introduction to Aspect-Oriented Programming with the Spring Framework Caldamente consigliato! An Introduction to Aspect-Oriented Programming with the Spring Framework ● Spring: A Developer's Notebook By Justin Gehtland, Bruce A. Tate

Domande...?

JUG – Ancona Italy Grazie ! Andrea Del Bene JUG Marche -