Quando utilizzare Windows Workflow Foundation? [chiuso]


154

Alcune cose sono più facili da implementare solo a mano (codice), ma alcune sono più facili tramite WF. Sembra che WF possa essere usato per creare (quasi) qualsiasi tipo di algoritmo. Quindi (teoricamente) posso fare tutta la mia logica in WF, ma probabilmente è una cattiva idea farlo per tutti i progetti.

In quali situazioni è una buona idea usare WF e quando renderanno le cose più difficili, allora devono essere? Quali sono i pro e i contro / i costi di WF rispetto alla codifica manuale?


3
Vale la pena notare che è stato completamente riscritto per la versione 4.0 che è uscita dopo queste risposte.
Sclarson,

Risposte:


125

Potrebbe essere necessario WF solo se si verifica una delle seguenti condizioni:

  1. Hai un processo di lunga durata.
  2. Hai un processo che cambia frequentemente.
  3. Vuoi un modello visivo del processo.

Per maggiori dettagli, vedi il post di Paul Andrew: Per cosa utilizzare Windows Workflow Foundation?

Si prega di non confondere o mettere in relazione WF con la programmazione visiva di alcun tipo. È sbagliato e può portare a pessime decisioni di architettura / design.


4
Qual è l'unità di misura per processi di lunga durata?
Ivorykoder,

5
I "processi" di @ivorykoder (in realtà flussi di lavoro ) che possono sopravvivere al riavvio del server che lo ospita.
lobsterism,

Se avessi requisiti che soddisfacessero solo il n. 1, non sarebbe abbastanza per me scegliere WF. Tuttavia, se i requisiti includessero # 2 e / o # 3, sarebbe un caso molto più forte per l'utilizzo di WF.
Mick,

12
Non posso resistere: potresti aver bisogno di WF solo se uno dei seguenti è vero: falso.
Ronnie Overby,

84

Mai. Probabilmente te ne pentirai:

  • Ripida curva di apprendimento
  • Difficile eseguire il debug
  • Difficile da mantenere
  • Non fornisce abbastanza potenza, flessibilità o guadagno di produttività per giustificarne l'uso
  • Può e vuole corrompere lo stato dell'applicazione che non può essere recuperato

L'unica volta che ho mai potuto immaginare di utilizzare WF è se volevo ospitare il designer per un utente finale e probabilmente nemmeno allora.

Fidati di me, niente sarà mai semplice, potente o flessibile come il codice che scrivi per fare esattamente quello che ti serve. Stai lontano da WF.

Certo, questa è solo la mia opinione, ma penso che sia dannatamente buona. :)


27
-1 rispetto la tua opinione su questo, ma apprezzo molto una spiegazione professionale del motivo. non vedo come questo tipo di risposta aiuti chiunque
danfromisrael,

9
Ho scritto questa risposta in un giorno in cui ero arrabbiato con WF4. Aggiornerò la mia risposta con i problemi che ho riscontrato.
Ronnie Overby, il

5
Abbiamo ereditato un progetto parzialmente completato da un consulente che utilizzava WF come backbone. Era soggetto a errori, flussi di lavoro corrotti che non possono essere riavviati, un sistema di controllo della versione arcaico che richiede un duplicato completo del flusso di lavoro per eventuali modifiche minori, codice generato orribile e un codice così delicato che devi gestirlo con guanti da bambino . Dopo 6 mesi di schermate gialle della morte abbiamo eliminato l'intero WF e usato invece xml. La migliore decisione che abbiamo mai preso.
Kevin DeVoe,

10
La frase: "Non fornisce abbastanza potenza, flessibilità o aumento della produttività per giustificarne l'uso", dice abbastanza per me. Grazie per questo.
David Tansey,

1
Gli odiatori devono spiegare il loro odio.
Ronnie Overby,

46

Il codice generato da WF è cattivo. Il valore che WF apporta è nella rappresentazione visiva del sistema, anche se non ho ancora visto nulla (6-7 progetti al lavoro ora con WF con cui sono stato coinvolto) in cui non avrei preferito un progetto codificato a mano più semplice .


40

In generale, se non hai bisogno delle funzionalità di persistenza e tracciamento (che a mio avviso sono le caratteristiche principali), non dovresti usare Workflow Foundation.

Ecco i vantaggi e gli svantaggi di Workflow Foundation che ho raccolto dalla mia esperienza:

vantaggi

  • Persistenza: se hai molti processi di lunga durata (pensa a giorni, settimane, mesi), i flussi di lavoro sono perfetti per questo. Le istanze del flusso di lavoro inattive vengono mantenute nel database in modo che non utilizzino memoria.
  • Tracciamento: WF fornisce il meccanismo per tenere traccia di ogni attività eseguita in un flusso di lavoro
  • * Visual Designer: lo metto come *, perché penso che sia davvero utile solo per scopi di marketing. Come sviluppatore, preferisco scrivere codice piuttosto che agganciare visivamente le cose. E quando hai un non sviluppatore che crea flussi di lavoro, spesso finisci con un enorme casino confuso.

svantaggi

  • Modello di programmazione: sei davvero limitato nelle funzioni di programmazione. Pensa a tutte le fantastiche funzionalità che hai in C #, quindi dimenticatene. Semplici istruzioni a una o due righe in C # diventano attività di blocco abbastanza grandi. Questo è particolarmente doloroso per la convalida dell'input. Detto questo, se stai davvero attento a mantenere solo la logica di alto livello nei flussi di lavoro e tutto il resto in C #, potrebbe non essere un problema.
  • Prestazioni: i flussi di lavoro consumano una grande quantità di memoria. Se stai distribuendo molti flussi di lavoro su un server, assicurati di avere tonnellate di memoria. Inoltre, tieni presente che i flussi di lavoro sono molto più lenti del normale codice C #.
  • Curva di apprendimento ripida, difficile da eseguire il debug: come menzionato sopra. Trascorrerai molto tempo a capire come far funzionare le cose e a capire il modo migliore per fare qualcosa.
  • Incompatibilità della versione del flusso di lavoro: se si distribuisce un flusso di lavoro con persistenza e si devono effettuare aggiornamenti al flusso di lavoro, le vecchie istanze del flusso di lavoro non sono più compatibili. Presumibilmente questo è stato risolto in .NET 4.5.
  • Devi usare espressioni VB (.NET 4.5 consente espressioni C #).
  • Non flessibile: se hai bisogno di alcune funzionalità speciali o specifiche non fornite da Workflow Foundation, preparati a molto dolore. In alcuni casi, potrebbe non essere nemmeno possibile. Chi lo sa fino a quando non ci provi? C'è molto rischio qui.
  • Servizi WCF XAML senza interfacce: normalmente con i servizi WCF, si sviluppa su un'interfaccia. Con i servizi XAML WCF, non è possibile garantire che un servizio XAML WCF abbia implementato tutto in un'interfaccia. Non è nemmeno necessario definire un'interfaccia. (per quanto ne so...)

7
La maggior parte dei tuoi svantaggi non è semplicemente vera, forse non hai abbastanza familiarità con WF. WF è molto flessibile. Ti consente di scrivere attività personalizzate (attività in codice) che puoi riutilizzare in qualsiasi scenario. Sta a te scrivere attività riutilizzabili. Immagina di essere in grado di fornire una GUI (app WPF con Workflow Designer Host) ai consulenti aziendali insieme a un set di strumenti di attività. Ora possono cambiare e riorganizzare la logica aziendale in base alle loro esigenze e non richiedono sviluppatori e persino compilare una nuova applicazione.
Sven,

3
Ora immagina che i consulenti aziendali debbano usare il tuo designer autonomo, ma senza Intellisense! O fai il tuo o devi usare Visual Studio. Penso anche che per i consulenti aziendali sarà difficile comprendere anche alcuni concetti come compensazione, cancellazione, gestione delle eccezioni. Inoltre, qualsiasi logica che sia lontanamente complessa da un evento provocherà un flusso di lavoro gigantesco che diventa irraggiungibile (oh, e avrai bisogno di tonnellate di ram per modificare tali flussi di lavoro). Hai ragione, però, con attività personalizzate accuratamente realizzate offrono una buona flessibilità.
Mas

27

Il motivo principale che ho scoperto per l'utilizzo della base del flusso di lavoro è quanto ti porta fuori dalla scatola in termini di tracciamento e persistenza. È molto semplice avviare il servizio di persistenza, che garantisce affidabilità e distribuzione del carico tra più istanze e host.

D'altra parte, proprio come le app per moduli, i modelli di codice che il designer del flusso di lavoro ti spinge verso sono cattivi. Ma puoi evitare problemi scrivendo nessun codice nel flusso di lavoro e delegando tutto il lavoro ad altre classi, che possono essere organizzate e testate in modo più elegante rispetto al flusso di lavoro. Quindi ottieni il fantastico aspetto visivo del designer senza l'innesto del codice spaghetti dietro.


11

Personalmente, non sono venduto su WF. La sua utilità non era così ovvia per me come altre nuove tecnologie MS, come WPF o WCF.

Penso che in futuro WF verrà utilizzato molto nelle applicazioni aziendali, ma non ho intenzione di usarlo perché non sembra lo strumento giusto per il lavoro per i miei progetti.


7

La società con cui sto attualmente lavorando per creare una Windows Workflow Foundation (WF) e i motivi per cui hanno scelto di utilizzarla è perché le regole sarebbero cambiate frequentemente e ciò li avrebbe costretti a fare una ricompilazione delle varie DLL ecc. E quindi la loro soluzione era quello di posizionare le regole nel DB e chiamarle da lì. In questo modo potrebbero cambiare le regole e non dover ricompilare e ridistribuire le dll ecc.


21
Peccato che i servizi e le applicazioni web normali non abbiano file .config, non possano leggere database, né leggere file XML o locali che contengono regole, senza ricompilazione. Oh aspetta ...
Dour High Arch,

6

I flussi di lavoro di Windows seducono responsabili IT, BA e simili non codificanti, così come suo cugino BizTalk, ma in pratica test di unità, debug e copertura del codice sono solo tre delle molte insidie. Puoi superarne alcuni, ma devi investire molto per raggiungerlo, mentre con un semplice codice lo ottieni. Se hai davvero un requisito di lunga durata, allora probabilmente hai bisogno di qualcosa di più sofisticato. Ho sentito l'argomento sulla possibilità di rilasciare nuovi file xaml in produzione senza ricompilare dll ma onestamente il tempo che i flussi di lavoro consumeranno potrebbe essere meglio utilizzato per migliorare la tua integrazione continua al punto in cui le distribuzioni compilate non sono un problema.


3

Lo userei in qualsiasi ambiente in cui ho bisogno di lavorare con il flusso di lavoro, tuttavia quando lo uso in combinazione con K2 o persino SharePoint 2007 la potenza della piattaforma è davvero utile. Quando si sviluppano applicazioni aziendali con specialisti della BI, si consiglia l'uso della piattaforma e questo sarebbe normalmente rilevante solo per semplificare e migliorare i processi aziendali.

Per la cronaca, WF è stato sviluppato in collaborazione con il team di sviluppo di K2 e il nuovo K2 Blackpearl è costruito sopra WF, così come MOSS 2007 e i motori di flusso di lavoro di WSS 3.0.


2

Quando non vuoi scrivere manualmente tutti quei codici per mantenere l'interfaccia visiva, il monitoraggio e la persistenza, è una scelta saggia votare per WF.


1

Uso il flusso di lavoro di Windows da mesi per sviluppare attività personalizzate e un designer ospitato di nuovo che i non sviluppatori possono utilizzare per creare flussi di lavoro. WF è molto potente ma è buono solo come le attività personalizzate sviluppate dagli sviluppatori. Quando si tratta di esso, uno sviluppatore dovrebbe esaminare i flussi di lavoro creati da non sviluppatori per testare ed eseguire il debug ma dal punto in cui possono creare bozze di flussi di lavoro, è fantastico.

Inoltre, nei casi in cui hai processi di lunga durata, WF è un buon stack tecnologico da utilizzare quando è necessario aggiornare i processi in modo dinamico - senza dover reinstallare / scaricare o fare nulla, basta aggiungere i nuovi file XAML a una directory e la tua architettura dovrebbe essere impostare con il controllo delle versioni per eliminare quello vecchio e utilizzare quello nuovo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.