Il pattern "Unit of Work"

Gestire i dati in maniera efficiente utilizzando un ORM e il patter UOW ("Unit Of Work").

Hibernate implementa in maniera nascosta all’utilizzatore il pattern “Unit of Work”. Tale funzionalità è implicita all’interno del meccanismo di sessione e transazione che espone. In pratica è l’esposizione dell’oggetto Session di Hibernate a garantire all’utilizzatore la possibilità di aggiungere un’operazione all’interno dell’UnitOfWork e quindi a premettere la realizzazione di operazioni transazionali. L’adozione di una classe centralizzata che si interfaccia con il database non garantisce di per se l’indipendenza dal framework Hibernate, volendo gestire in transazione una serie di operazioni, in quanto dovendo esporre gli oggetti Session e Transaction, che sono propri di Hibernate, si crea una dipendenza forte dalla libreria. Per realizzare una funzionalità veramente indipendente è necessario introdurre il concetto di UnitOfWork ad un livello più alto, in modo tale che anche l’utilizzatore adotti solo concetti propri . Così facendo sarà possibile cambiare framework per l’accesso ai dati in maniera trasparente per l’applicazione. Molti framework o prodotti commerciali soddisfano questo requisito incapsulando gli oggetti tipici dell’accesso ai dati in classi propri. Questo approccio è sicuramente efficace e di facile implementazione tuttavia vincola l’applicazione a ragionare sempre seguendo le modalità stabilite all’interno di Hibernate. Per assurdo, se fosse stato proprio uno di questi principi a portare al cambio di libreria, al termine dell’operazione  il problema rimarrebbe immutato. L’approccio di implementare esplicitamente il pattern UnitOfWork risulta leggermente più complesso ma:

 

  1. Permette di rendere veramente indipendente la piattaforma dalla libreria, poiché:
    1. Vincola la piattaforma ad adottare un pattern generico, e non un pattern specifico,
    2. Adotta solo costrutti interni all’applicazione,
  2. Permette di effettuare fine tuning dell’applicazione
    1. Accentrando tutte le funzionalità, compresa la gestione delle sessioni e transazioni
  3. Permette di adottare approcci all’accesso dati diversi, contemporaneamente
    1. Tramite l’adozione di interfacce e implementazioni diverse,
    2. Grazie all’adozione di Ioc o reflection per l’istanziazione dell’implementazione corretta

Per il momento la dipendenza forte da Hibernate è considerata accettabile, andrà valutato nei prossimi release se valga la pena implementare tali funzionalità per mantenere la possibilità di modificare framework in futuro.

Credo di voler dire una cosa sensata. Forse però mi devo spiegare meglio…

danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento