Dunque....per capire dove possiamo applicare workflow, possiamo partire da questo post che spiega quale tipo di workflow usare e quando.
Sintetizzo una parte importante:
"quando bisogna prendere delle decisioni dall'esterno del workflow, conviene usare una macchina a stati, diversamente conviene il sequenziale"
Ho mooooolto sintetizzato! Conviene leggersi tutto il post.
Perchè parto da questa considerazione? Semplice: è il punto di partenza per comprendere dove possiamo infilare Workflow!
Riflettiamoci un attimo ragionando su un problema molto frequente: l'ordine di un sito web di commercio elettronico. Non vi viene in mente nulla?
Innanzitutto è un problema che richiede interventi esterni: immissione dell'ordine, preparazione, spedizione, consegna. Vi dice nulla? A me dice: "qui ci vuole una State Machine"! E guardacaso, nell'SDK di Workflow Foundation, c'è proprio un esempio a riguardo di cui vi allego l'immagine:
Ora, un ordine di un sito di e-commerce si è sempre potuto gestire. Ma con una macchina a stati fatta con WWF si hanno sicuramente una serie di vantaggi in più:
- rapidità nello sviluppo
- migliore controllo del flusso (lo vedi...è lì!)
- semplicità di manutenzione
- riduzione del codice da scrivere (guardatevi l'esempio sul call center, sempre nell'SDK, e provate a rifarlo senza WWF)
- più flessibilità: il vostro workflow (o la macchina a stati in questo caso), può essere usata direttamente, richiamata da un web service, persistita su un DB, tracciata.
Di applicazioni paragonabili ad un ordine ce ne sono tante.
Ed i sequenziali? Ripartiamo dalla sintesi del post che ho linkato: conviene usarli quando non c'è da prendere una decisione dall'esterno. Quindi?
Un ordine di un sito web! Ma come direte voi, non c'era la macchina a stati?
Certo....ma voi all'ordine ci dvete pure arrivare in qualche modo. Vi dice niente: verifica della identità del cliente (è loggato? l'account è attivo? ha promozioni in corso?), il controllo della disponibilità in magazzino, il controllo sulle scorte minime, il prodotto omaggio, la validazione della carta di credito etc.
Tutte cose fatte e rifatte, ma volete mettere la comodità di usare Workflow Foundation per farlo?
Il vostro workflow sequenziale preparerà i dati che manderà alla macchina a stati per la gestione dell'ordine! Bello no?
Mi si può obiettare che così si perde il contatto con il codice: troppo drag'n'drop e troppo visuale. Chi mi conosce bene sa che ODIO le applicazioni fatte trascinando gli elementi sull'interfaccia (in vita mia ne ho fatta una sola ed è venuta pure male), ma vi assicuro che, quando sviluppo una applicazione windows, i bottoni e le label le trascino! Non stò a perdere la testa a posizionarle via codice.
Che vuol dire? Semplicemente che, con Workflow Foundation, voi trascinate le activity sul designer, le collegate, gli assegnate un nome. Ma se non ci scrivete un codice dietro, il Workflow non funzionerà!
Ecco quindi qual'è la comodità di questo strumento: disegnare un flusso di informazioni, che poi dobbiamo implementare. Non disegnare un software.
Tornando all'oggetto di questo post "scenari", la risposta è: molti più scenari di quanti ne immagini! Ti basta trovare un caso in cui l'esecuzione del sofware NON chiede interazione e puoi usare un sequenziale ed un caso in cui è richiesta interazione per metterci una macchina a stati.
Ovviamente, a questo punto, va fatta una considerazione: ricordiamoci sempre che workflow vive in un thread separato e grazie ad un runtime. Questo vuol dire che tutte le comodità che Workflow fornisce hanno un costo che va sepre valutato. In pratica, se devi implemetare una procedra di login ad un sito, sebbene possa essere fatto con workflow, è sconveniente in termini di risorse e di implementazione. Ti posso assicurare però una cosa: se oggi mi si dovesse chiedere di implementare un e-commerce (non del pasticciere che ho sotto l'ufficio ovviamente), per la gestione degli ordini userei una macchina a stati ed un workflow sequenziale.
Spero di aver chiarito i dubbi. Se avete domande, son qui!