Quando utilizzare Windows Workflow Foundation? [chiuso]

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?

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.

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. :)

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 .

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...)

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.

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.

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.

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.

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.

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

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.