Un progetto la cui architettura sta emergendo in questi giorni, ha evidenziato una problematica ricorrente che riguarda la necessità o meno di strutturare i dati in modo relazionale nel database.
Per evitare di farla troppo lunga, partiamo da un esempio. Diciamo quindi di avere un modulo di una applicazione che deve eseguire del logging sulle attività svolte da un utente all'interno di un sito.
L'attività da loggare è ha un inizio, i dati da loggare cambiano a seconda di come opera l'utente nell'applicazione, termina quando l'utente ha completato un determinato task, il log deve essere cancellato dopo un certo tempo perché lo storico non sia eccessivo e per rispettare la privacy.
Il database è lo strumento ideale per mantenere questi dati? Se consideriamo il modo "classico" di gestione del database la mia risposta è no.
Facciamo un passo indietro e domandiamoci perché si sceglie il database. I motivi in cima alla lista sono: gestione "gratis" della concorrenza nell'accesso ai dati, ottime performance nella ricerca dei dati, capacità di relazionare set di dati eterogenei, etc.
Ma nel nostro esempio cosa ci serve di tutto ciò? Più che altro ci serve la gestione della concorrenza per cui sarebbe da pazzi eseguire la persistenza su un file xml.
Quale altra tecnologia ci permette di rispondere a quelle domande per lo specifico problema in esempio? Workflow Foundation non solo risponde a questi requisiti ma semplifica di parecchio lo sviluppo della soluzione:
- Alla crezione del nuovo log, viene creato una nuova istanza di workflow
- Dalla versione 4.0 possiamo gestire la logica del nostro esempio di logging (e i relativi dati) secondo una Flowchart, cosa particolarmente familiare a qualsiasi developer, quindi meno prona ad errori.
- I workflow possono essere "long-running" e sarà l'engine a gestirne la persistenza sul "media" che il developer ha stabilito. La persistenza può anche finire in un blob così come su un db relazionale. Il tutto è "nascosto" all'applicazione e come ogni disaccoppiamento questo è un grosso beneficio.
- L'avanzamento dell'attività dell'utente si ottiene dall'object model di Workflow, anche da una applicazione esterna di amministrazione. A partire dalla versione 4.0 ci sono anche gli strumenti già pronti come la dashboard di "Dublin".
- Il workflow può avere come ultimo stadio una "Sleep" di 2 mesi e poi decidere di cancellare la persistenza. Quei due mesi non sono altro che un blob posteggiato da qualche parte. In memoria non c'è nulla ma il runtime sa che, tascorso quel tempo, deve riattivare quell'istanza e farla proseguire. Il suo ultimo stadio è quello della cancellazione dello storico.
In sostanza basta disegnare graficamente il workflow, oops flowchart, (magari dopo aver sviluppato delle adeguate custom activity) e dirgli che ci serve il servizio di persistenza, e il gioco è fatto.
Magari abbiamo configurato la persistenza di WF su un db relazionale, o magari abbiamo usato Table o Blob di Windows Azure, ma quel che più importa è che non abbiamo disegnato un db, non abbiamo scritto query o sp, non abbiamo un datalayer per questa specifica parte dell'applicazione.
Ovviamente il concetto è trasportabile anche a molti altri esempi ma non è generalizzabile anche se ritengo che l'abitudine ad usare il db per tutta la persistenza nasconda soluzioni più brillanti.