Database – Come gestire le transazioni in Zend Framework

giugno 11th, 2010 - (4 Comments)



Zend Framework è uno tra i principali framework (se non il principale) per lo sviluppo di applicazioni enterprise in PHP. E’ uno strumento molto potente al servizio degli sviluppatori PHP: è estremamente flessibile, estendibile, facile da usare e decisamente manutenibile. Questo è il primo di una serie di articoli che sto preparando per presentare quelle che sono le caratteristiche più interessanti di questo prodotto.

L’argomento che trattiamo in questo articolo è la gestione delle transazioni con Zend Framework. Una transazione è una sequenza di operazioni che deve rispettare le proprietà ACID ( Atomicity, Consistency, Isolation, e DurabilityAtomicità, Coerenza, Isolamento e Durabilità). Una transazione può terminare con successo o con un insuccesso: nel primo caso il risultato sarà permamente, mentre nel caso di insuccesso di deve tornare alla situazione precedente l’inizio della transazione, come se nulla fosse successo.

Una transazione inizia con l’istruzione che dichiara appunto l’ “inizio della transazione” ( il punto (1) nel codice). Le operazioni che intendiamo eseguire tutte insieme sul database vanno inseriti dopo questa istruzione (1), all’interno di un blocco “try{} catch {}” che permette di verificare che tutto abbia funzionanto e pertanto che non siano state lanciate eccezioni.

Nel nostro esempio vogliamo eseguire due operazioni di inserimento sul database (2), utilizzando i modelli “$model” e “$model2″ (Zend Framework si basa su una implementazione del pattern MVC, Model-View-Controller). Vorremmo che queste operazioni di inserimento avvennissero una dopo l’altra, e che vengano annullate nel caso in cui una delle due “INSERT” non andasse a buon fine. I dati che vogliamo inserire li organizziamo in una struttura dati simile a quella nel punto (3) del codice (in sostanza un array associativo).

Nei punti (4) e (5) dell’esempio effettuiamo gli inserimenti veri e propri. Se tutto funziona senza problemi, effettuiamo l’operazione di COMMIT (6) per confermare la correttezza della transazione e dunque la conseguente chiusura della stessa.

Nel caso in cui invece  si siano verificati problemi, verrà lanciata una eccezione che sarà catturata dal blocco “catch”, nel quale, prima di riportare il messaggio dell’errore e lanciarlo alla classe padre (8), eseguiamo l’azione di ROLLBACK (7). Questa è l’istruzione che comunica alla transazione che ci sono stati problemi e che dunque deve essere annullata, senza apportare modifiche permanenti alla base di dati.

(1) $this->getAdapter()->beginTransaction();
try {

  // TODO ho aggiunto io l’autoincrement nelle tabelle articoli
  (2) $model   = new My_Model();
  $model2 = new My_Model2();
  (3) $data   = array("nome"=>"Marco", "cognome"=>"Lecce");
  $data2 = array("tipo"=>"Utente", "ruolo"=>"Editore");
  (4) $id = $model->insert($data);
  (5) $id2 = $model2->insert($data2);

  (6) $this->getAdapter()->commit();

} catch ( Zend_Exception $e ) {

  (7) $this->getAdapter()->rollBack();
  (8) throw new Exception( $e->getMessage() );

}

Come abbiamo visto sono sufficienti queste poche righe di codice per gestire un importante concetto come quello delle transazioni. Il codice rimane dunque pulito e molto leggibile: per ora è tutto, ci vediamo al prossimo articolo con Zend Framework! ;)

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

4 Responses

  • marco says:

    In linea di massima sono d’accordo con quanto affermi, anche se credo che andrebbe sottolineanto un punto fondamentale.

    Lo scopo di ZF è quello, tra le altre cose, di mettere un pò di ordine nell’ambiente PHP. Chiaramente, essendo implementato in PHP, si porta dietro tutte le criticità di questo linguaggio.

    ZF è UNA possiblità per sviluppare applicativi enterprise (in PHP): come dici giustamente tu, bisogna tenere presente tutte le problematiche di prestazioni e di gestione delle risorse, ma questo si fa in fase di progettazione. Ad esempio, durante l’analisi del progetto può risultare che PHP sia inadeguato per gli scopi dell’applicativo, e dunque le scelte cadranno su tecnologie che rispondono in maniera più performante agli scopi del progetto.

    Per quanto riguarda invece l’uso di Ajax, sono d’accordo solo in parte: credo che Ajax sia anche un modo per migliorare l’esperienza di navigazione dell’utente e l’interfaccia dell’applicativo, e non è una cosa da sottovalutare. Il Web è pieno di progetti fenomenali che sono morti perchè nel tempo sono risultati poco “usabili”.

    Credo invece che hai pienamente ragione quando dici che ogni cosa ha pregi e difetti: ZF non risolve tutti i problemi, e deve essere il progetto a “consigliarlo”. :em21:

  • skyblackhawk says:

    Il framework Zend non e’ nulla di nuovo per chi lavora nel settore IT. E’ l’industrializzazione di un pattern molto noto per chi lavora nell’IT.

    Per grossi progetti, la maggioranza delle persone che abbiano lavorato in ambiente finalizzati al delivery si siano creati il proprio pattern.
    Da 8 anni a questa parte finalmente nella comunita’ PHP è entrata la mentalita’ dei pattern. Credo che prima non fosse cosi’ diffusa perche’ la maggioranza degli utilizzatori pensava che i pattern fossero una palla e fosse meglio fallo artigianalmente il codice.

    Errore madornale per i non professionisti, costi elevati e lavoro stressante e ripetitivo.

    Oggi esistono diversi framework che permettono di sfruttare questo pattern. Una volta lo si sviluppava a mano.

    Quindi che dire. Un grazie per chi ha sviluppato il pattern così si evita quando si entra in un nuovo progetto di reingegnerizzarlo perchè si suppone che il proprio pattern di riferimento sia migliore. Dall’altra parte però credo che chi deve usare Zend debba comprendere tutti i limiti di questo framework.

    Primo fra tutti la gestione delle classi, interfacce, ecc. per intenderci la gestione di questi oggetti in PHP che non è insito nel linguaggio e per questo gestito tuttora come array generici.

    Il framework velocizza lo sviluppo ok, ma alla fine il cliente vuole vedere anche le performance dell’applicazione che ha commissionato.

    Usare troppo l’astrazione che non appartiene decisamente al linguaggio di un computer significa sovraccaricare il server di puntatori che rimbalzano da una parte all’altra della memoria e spesso swappando sul disco.

    Ora bisogna comprendere che l’astrazione aiuta nello sviluppo ma nella pratica rallenta il prodotto finale.

    E’ una critica che credo che chiunque condivida e conosca perfettamente.

    Upscaling di server in load balancing ne abbiamo visti a bizzeffe.

    Poi se aggiungete l’uso di AJAX per applicazioni web di grosse dimensione per multinazionali c’e’ da uccidersi. Alle volte bisogna inviare codice a iosa ai client che non sono 10 ma 10000 ed il server è continuamente impegnato a generare il codice javascript customizzato alla richiesta.

    Insomma una pazzia decisa da chi sponsorizza il Web 2.0 che è una pura scelta di marketing.
    Ossia non far vedere al cliente che il server lavora e la risposta non è immediata, ma lasciare parte del lavoro al client non sapendo che tutta la business logic è sul server per centralizzare i processi.
    In più aggiungere lavoro di sviluppo per i vari browser che evolveranno.

    Questo modello client server è fallito in passato. Quanti di noi ricordano le innumerevoli librerie javascript che uscivano dal 1998 in avanti.

    Insomma un lavoraccio per vedere alla fine cosa? che la pagina in un determinato momento non era bianca o ferma.

    Bella soluzione da markettari intesa come marketing.

    Quindi Zend ha fatto bene a normalizzare il pattern MVC ed è un merito, ma attenzione come ogni cosa ha pregi e difetti (soprattutto +astrazione corrisponde a +risorse del server).

    Non so se condividerete il mio punto di vista, ma lo spero.

    Ciao

  • Pingback: Zend Framework e i context JSON, HTML e XML

  • Pingback: Technotizie.it



Leave a Reply

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

*

È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">