2011-01-13 13 views
7

Devo progettare e implementare un modo per gestire i processi di lunga durata in un'applicazione client/server. Un tipico processo di lunga durata richiederebbe/potrebbe richiedere 2-3 minuti. Devo anche segnalare i progressi nell'interfaccia utente nel frattempo e mantenere l'interfaccia utente reattiva.Notifica di avanzamento in WCF per processi di lunga durata - Come?

Avendo questi nella mia mente anche se, alcune soluzioni:

  • Una richiesta asincrona per avviare il processo che avvia il processo sul lato server e restituisce un LRPID assegnato (Long esecuzione Process ID) poi sondare periodicamente dal client utilizzando tale LRPID. (Pro: semplice da implementare, senza firewall fare in giro Con: Unelegant, consumo di risorse, ecc)

  • Utilizzare un duplex vincolante (come NetTcpBinding) e di avviare callback dal server, come si stanno facendo progressi (Pro: Elegante, efficiente, Con: distribuzione incubo)

  • [Il tuo suggerimento ???]

Quale sarebbe la tua opinione su questo?

+0

Qual è l'applicazione lato client scritto in? –

+0

Incubo di distribuzione? Perché, a causa di IIS/WAS? Quindi non li usano. –

+0

@Daniel Auger: l'app client è scritta in WPF –

risposta

4

Ecco un post di Dan Wahlin su come creare un indicatore di avanzamento WCF per un'applicazione Silverlight. Questo dovrebbe essere di qualche aiuto.

+0

sembra abbastanza bello, dovrò guardare un po 'di più.Grazie! –

+0

Ok, questa si è rivelata la migliore via di mezzo! Soprattutto perché '" ... Avvia una richiesta di rete, quindi la richiesta è effettivamente "messa a riposo" in attesa che il server risponda (non torna immediatamente). Il server mantiene quindi la connessione aperta ma non attiva fino a quando non ha qualcosa da rispedire (o la connessione scade dopo 90 secondi - a quel punto il client duplex si connetterà di nuovo e aspetterà). In questo modo si evita di colpire ripetutamente il server, ma si ottiene comunque una risposta immediata quando ci sono dati " –

+0

o in altre parole, un sistema di polling leggero, già implementato, che simula una versione a due vie –

1

Se non si vuole preoccuparsi del firewall del client, ecc ... Probabilmente andrei con la prima soluzione e userei uno BackGroundWorker per effettuare la chiamata per evitare di bloccare il thread dell'interfaccia utente. L'ho fatto di recente per un'app in cui una richiesta di generare un rapporto viene messa in coda e recuperata una volta eseguita. Sembra che funzioni bene.

0

Un altro modo (senza dover modificare l'associazione WCF) consiste nell'utilizzare un controllo WebBrowser nel client WPF e SignalR per inviare messaggi di stato dal server a tale controllo.

Si noti che per evitare errori javascript che si verificano con il controllo WebBrowser (poiché per impostazione predefinita sembra utilizzare Internet Explorer versione 7 che non sembra essere compatibile con jQuery.js), sarà necessario aggiungere le chiavi al Registro di sistema sul computer client per modificare l'impostazione predefinita per l'app client per utilizzare IE10 o successivo - vedere http://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version. Questo potrebbe essere un fastidio per l'implementazione (perché i diritti di amministrazione sembrano essere necessari, ad esempio su un Windows 8.1 a 64 bit, per aggiungere le chiavi di registro). Inoltre, sembra ancora necessario chiamare il metodo WCF con esecuzione prolungata in un thread separato, altrimenti il ​​controllo WebBrowser non sembra aggiornare la sua visualizzazione per mostrare i messaggi SignalR che sta ricevendo. (Questo ha senso perché il thread dell'interfaccia utente dovrebbe altrimenti attendere fino al termine della chiamata WCF).

Ma ho citato come un approccio alternativo utilizzando uno strumento più recente (SignalR) :)