2013-03-07 8 views
27

Mam jedną aplikację klient-serwer WPF. Teraz mam scenariusz taki jak klient połączy się z serwerem, a serwer będzie okresowo przesyłać dane do klienta. Jestem nieco zdezorientowany tym, jaką technologię i sposób powinienem wybrać, aby powiadomić klientów.Przekaż dane do klienta za pomocą SignalR vs WCF?

SignalR jest najlepszy do aplikacji internetowej, myślę, że mam aplikację na komputer. Dzięki usłudze WCF możemy realizować powiadomienia push poprzez kanał Duplex i wywołanie zwrotne. Czy możesz mi doradzić jakie są zalety i wady korzystania z usługi SignalR lub WCF?

Dzięki

Odpowiedz

18

Poniżej są moje obserwacje z doświadczeń:

SignalR plusy:

  • Łatwy uruchomieniem niższa krzywa uczenia się. można łatwo uruchomić przykład znalezione w internecie
  • Obsługa wyjątków (np gra krople, timeout) jest osadzony wewnątrz API

SignalR Wady:

  • Tylko wspierając protokół HTTP

Zalety dupleksu:

  • Obsługuje protokół TCP oprócz HTTP. Może to być poważny wzrost wydajności, jeśli znasz typy klientów i system działa w zamkniętej sieci. Również praca nad TCP dodaje większą stabilność połączenia niż HTTP

Duplex Wady:

  • Wyższą krzywej uczenia się - trudniejsze do uruchamiania i stabilnych rozwiązań. Chcesz to zweryfikować? Pobierz dupleks i próbkę SignalR z internetu i sprawdź, ile czasu poświęcisz na wzajemne sukcesy.
  • Musisz obsłużyć wszystkich wyjątkowych przypadków (połączenie krople, limity czasu, itd.)
  • wiem, że nie jestem jedynym, który w obliczu poważnych problemów limitu czasu, gdy chcesz korzystać z usługi drukowania dwustronnego przez długi czas. Musimy okresowo wykonywać zgłoszenia serwisowe, aby utrzymać połączenia klientów przy życiu.

Nawiasem mówiąc, istnieją API dla projektów JavaScript, Desktop i Silverlight do korzystania z usług SignalR.

+0

Dzięki za odpowiedź. Jestem już świadomy komunikacji duplex WCF, jak to zrobiłem w jednym z moich poprzednich projektów. A więc z punktu widzenia rozwoju, nie jest to dla mnie trudne. Chcę tylko poznać wydajność. Czy WCF stworzy jakiś problem, gdy aplikacja będzie dysponować dużymi danymi, które będą wtrącać się w ułamek czasu lub jakiejkolwiek kwestii przekroczenia limitu czasu, gdy jest ona bezczynna przez długi czas? –

+0

Nie wykonuję jeszcze testu wydajności w moich usługach druku dwustronnego. Ale w przypadku pytania o timeout, o którym wspomniałem w swojej odpowiedzi, napotkaliśmy pewne niedeterministyczne problemy z przekroczeniem limitu czasu podczas programowania. Ponieważ nie udało nam się znaleźć udokumentowanego rozwiązania i w pełni działającej próbki, postanowiliśmy ręcznie wprowadzić okresowe żądania pulsu do naszej usługi drukowania dwustronnego, aby utrzymać ją przy życiu (= aby zapobiec przekroczeniu limitu czasu połączenia). – Hasan

+1

SignalR obsługuje WebSockets (dla IIS 8), co w większości przypadków jest lepsze niż zwykły TCP, ponieważ lepiej przechodzić przez firewall. – Aron

4

SignalR nie chodzi tylko o internecie. Kod po stronie serwera SignalR nie dba o technologię swoich klientów, wystarczy mieć programistów po stronie klienta.

Jeśli izolujemy dane pusingowe od klienta, zdecydowanie polecam SignalR, ponieważ jest to o wiele prostsze niż WCF w tym aspekcie. Miałem udział w problemach z WCF i myślę, że miałeś trochę własnego. Znalazłem prostą próbkę aplikacji konsolowej/internetowej here.

Ogólnie rzecz biorąc, funkcja Duplex WCF i korzystanie z funkcji oddzwaniania, takiej jak here, wydają mi się bardzo kłopotliwe, istnieje wiele problemów związanych z konfiguracją serwera i dlatego myślę, że SignalR jest prostszy.

Ponadto nie można używać dupleksu (AFAIK) z javascript i target-c.

+0

Czy możesz podać więcej szczegółów o tym, dlaczego SignalR jest prostszy od WCF? –

+0

Edytowałem odpowiedź, ale zasadniczo uważam, że konfiguracja WCF jest bardzo niechlujna, a SignalR to bardzo eleganckie rozwiązanie, ale może to tylko kwestia gustu. Jestem jednak pewien, że SignalR zapewni większą elastyczność w przyszłości, jeśli chcesz dodać klienta WWW lub dowolną inną. – Mithir

+0

Chcę również sprawdzić wydajność, tylko dla celów kodowania nie możemy wybrać SignalR. Mam aplikację na komputery i nie będzie żadnej aplikacji internetowej w przyszłości. Również SignalR działa tylko na protokole Http, jak sądzę, czy SignalR obsługuje Net TCP? –

1

Jeden punkt, że nikt nie został podniesiony do tej pory:

  • SignalR 1.0.1 wymaga .NET 4 na serwer i klienta. W zależności od wersji ważnym czynnikiem, który należy wziąć pod uwagę, jest wersja klienta i serwera, na którą kierujesz ten numer: .

Jeśli chcesz tylko okresowo aktualizować nowe dane, lepiej po prostu użyć funkcji WCF i mechanizmu odpytywania od strony klienta, zamiast używać funkcji duplex WCF lub signalr.

+0

Jeśli przejdziemy do mechanizmu odpytywania, to nawet brak wymaganej usługi WCF. Ale w przypadku odpytywania pojawi się opóźnienie w uzyskaniu danych, jeśli czas odpytywania jest większy i nie możemy ustawić mniejszego czasu odpytywania i zaktualizować interfejsu użytkownika po stronie klienta. Również w przypadku sondowania musimy zachować bieżące dane, nie możemy załadować wszystkich danych przy każdym głosowaniu. –

3

Myślę, że masz już dużo danych na temat każdego z nich. Ale wybór SignalR zapewni dodatkową korzyść w stosunku do wysiłków na rzecz rozwoju, który w większości przypadków stanowi główny blok decyzyjny przy wyborze technologii.

Nie musisz martwić się o tworzenie/testowanie API itp. I możesz skupić się na własnej implementacji projektu.

Mam nadzieję, że pomoże!

2

SignalR można z łatwością używać teraz z wieloma klientami z javascript, .NET zarówno WinForms, jak i WPF, a nawet używać z klientem C++; Używanie samoobsługowego serwera .NET signalr (OWIN) jest naprawdę dobrym sposobem na posiadanie niezależnego serwera, który przesyła/odbiera/nadaje do wielu klientów. Jedyne, co może być łatwiejsze, to ZeroMQ, używając metody publikowania subskrybcji.