Powiadomienie o postępie w WCF dla długotrwałych procesów - jak?

Muszę zaprojektować i wdrożyć sposób radzenia sobie z długimi procesami w aplikacji klient/serwer. Typowy długotrwały proces mógłby zająć 2-3 minuty. W międzyczasie muszę też zgłaszać postępy do interfejsu użytkownika i dbać o to, aby interfejs był responsywny.Powiadomienie o postępie w WCF dla długotrwałych procesów - jak?

uwzględniając je w moim umyśle I choć od kilku rozwiązań:

jedną prośbę asynchronicznej, aby rozpocząć proces, który rozpoczyna proces po stronie serwera i zwraca przypisany LRPID (Long Running identyfikator procesu) następnie ankieta okresowo od klienta za pomocą tego LRPID. (Pro: prosty w instalacji, nie firewall aprowizacji Con: Unelegant, zużywa zasobów itd.)
Użyj DUPLEKSIE (takich jak netTcpBinding) oraz inicjowanie wywołań zwrotnych z serwera, jak dokonuje się postęp (Pro:, wydajny Con Elegant: koszmar Deployment)
[Twoja sugestia ???]

Co byś na to wpadł?

Źródło

2011-01-13 Andrei Rînea

Co jest napisane po stronie klienta? –

Wdrożenie koszmar? Dlaczego, z powodu IIS/WAS? Więc nie używaj ich. –

@ Daniel Auger: Aplikacja kliencka jest napisana w WPF –

Tutaj jest post autorstwa Dan Wahlin o tym, jak utworzyć wskaźnik postępu WCF dla aplikacji Silverlight. To powinno być pomocne.

Źródło

2011-01-13 21:54:49

wygląda całkiem fajnie, będę musiał wyglądać trochę bardziej.Dzięki! –

Ok, to okazało się najlepszym środkowym sposobem! Zwłaszcza, że '" ... inicjuje żądanie sieciowe, a następnie żądanie jest skutecznie "uśpione", czekając na odpowiedź serwera (nie wraca natychmiast) Serwer utrzymuje połączenie otwarte, ale nieaktywne dopóki nie ma czegoś do odesłania (lub czasu połączenia po 90 sekundach - w tym momencie klient dupleksu połączy się ponownie i poczeka) W ten sposób unikasz wielokrotnego trafiania na serwer - ale wciąż otrzymujesz natychmiastową odpowiedź, gdy są dane wysłać. "' –

lub innymi słowy, już wdrożony, lekki i efektywny system pollingu, który symuluje wersję dwukierunkową –

Jeśli nie chcesz się martwić zaporą klienta, itp. Prawdopodobnie skorzystam z Twojego pierwszego rozwiązania i użyję numeru BackGroundWorker, aby nawiązać połączenie, aby nie blokować wątku interfejsu użytkownika. Zrobiłem to ostatnio dla aplikacji, w której żądanie wygenerowania raportu jest umieszczane w kolejce i jest pobierane po zakończeniu. Wygląda na to, że działa dobrze.

Źródło

2011-01-16 21:27:43

Innym sposobem (bez konieczności zmiany wiązania WCF) jest użycie formantu WebBrowser w kliencie WPF i SignalR do wysyłania komunikatów o postępie z serwera do tego formantu.

Należy pamiętać, że aby uniknąć błędów javascript występujących w formancie WebBrowser (ponieważ domyślnie używa się przeglądarki Internet Explorer w wersji 7, która nie wydaje się być zgodna z jQuery.js), należy dodać klucze do rejestru na komputerze klienta, aby zmienić domyślne ustawienia aplikacji klienckiej na IE10 lub nowsze - patrz http://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version). Może to być uciążliwe rozmieszczenie (ponieważ uprawnienia administratora wydają się być potrzebne - np. Na 64-bitowym komputerze z systemem Windows 8.1 - w celu dodania kluczy rejestru). Ponadto nadal konieczne jest wywoływanie długo działającej metody WCF w osobnym wątku, w przeciwnym razie kontrolka WebBrowser nie wydaje się aktualizować swojego wyświetlacza, aby wyświetlić odbierane komunikaty SignalR. (Ma to sens, ponieważ wątek UI musiałby w innym wypadku poczekać do zakończenia wywołania WCF).

Ale wspominam o tym jako o alternatywnym podejściu przy użyciu nowszego narzędzia (SignalR) :)

Źródło

2014-08-07 11:52:13 patrickL

Powiadomienie o postępie w WCF dla długotrwałych procesów - jak?

Odpowiedz

Powiązane problemy