Sygnalizujący: Dlaczego warto wybrać centrum kontra trwałe połączenie?


150

Ostatnio szukałem i czytałem w SignalR i chociaż widzę wiele wyjaśnień na temat różnicy między hubami i trwałymi połączeniami, nie byłem w stanie przejść do następnego poziomu, dlatego powinienem wybrać jedno podejście zamiast drugiego?

Odpowiedzi:


92

Z tego, co widzę w sekcji Połączenia i centra , wydaje się, że centra zapewniają system tematyczny nakładający się na połączenia trwałe niższego poziomu.

Z wysoko ocenionego komentarza poniżej:

Częściowo poprawne. Możesz również uzyskać tematy lub grupy w stałych połączeniach. Duża różnica polega na wysyłaniu różnych typów wiadomości. Na przykład masz różne rodzaje wiadomości i chcesz wysyłać różne rodzaje ładunków. W przypadku połączeń trwałych musisz osadzić typ wiadomości w ładunku (patrz przykład Raw), ale koncentratory umożliwiają wykonywanie RPC przez połączenie (umożliwia wywoływanie metod na kliencie z serwera i z serwera do klienta) . Kolejną ważną rzeczą jest powiązanie modelu. Centra umożliwiają przekazywanie parametrów o jednoznacznie określonym typie do metod.

Przykład użyty w dokumentacji wykorzystuje metaforę pokoju rozmów, w której użytkownicy mogą dołączyć do określonego pokoju, a następnie otrzymywać wiadomości tylko od innych użytkowników w tym samym pokoju. Bardziej ogólnie, twój kod subskrybuje temat, a następnie otrzymuje tylko wiadomości publikowane w tym temacie. Dzięki trwałym połączeniom otrzymasz wszystkie wiadomości.

Możesz łatwo zbudować własny system tematów na podstawie trwałych połączeń, ale w tym przypadku zespół SignalR już wykonał pracę za Ciebie.


180
Częściowo poprawne. Możesz również uzyskać tematy lub grupy w stałych połączeniach. Duża różnica polega na wysyłaniu różnych typów wiadomości. Na przykład masz różne rodzaje wiadomości i chcesz wysyłać różne rodzaje ładunków. W przypadku połączeń trwałych musisz osadzić typ wiadomości w ładunku (patrz przykład Raw), ale koncentratory umożliwiają wykonywanie RPC przez połączenie (umożliwia wywoływanie metod na kliencie z serwera i z serwera do klienta) . Kolejną ważną rzeczą jest powiązanie modelu. Centra umożliwiają przekazywanie parametrów o jednoznacznie określonym typie do metod.
davidfowl

1
Słuszna uwaga @davidfowl - skopiowałem Twój komentarz do odpowiedzi, ponieważ myślę, że powinien być bardziej widoczny.
ColinE,

63

Główna różnica polega na tym, że nie można wykonać RPC z PersistentConnection, można wysyłać tylko surowe dane. Więc zamiast wysyłać wiadomości z serwera w ten sposób

Clients.All.addNewMessageToPage(name, message);

musiałbyś wysłać obiekt z Connection.Broadcast()lub, Connection.Send()a wtedy klient musiałby zdecydować, co z tym zrobić. Możesz na przykład wysłać taki obiekt:

Connection.Broadcast(new {
    method: "addNewMessageToPage",
    name: "Albert",
    message: "Hello"
});

I na kliencie, zamiast po prostu definiować

yourHub.client.addNewMessageToPage = function(name, message) { 
    // things and stuff
};

musiałbyś dodać callback do obsługi wszystkich przychodzących wiadomości:

function addNewMessageToPage(name, message) {
    // things and stuff
}

connection.received(function (data) {
    var method = data.method;

    window[method](data.name, data.message);
});

W tej OnReceivedmetodzie musiałbyś wykonać ten sam rodzaj wysyłania po stronie serwera . Będziesz również musiał deserializować tam ciąg danych zamiast odbierać obiekty o jednoznacznie określonym typie, tak jak w przypadku metod centrum.

Nie ma wielu powodów, dla których warto wybrać PersistentConnection przez Hubs. Jednym z powodów, dla których jestem świadomy, jest to, że możliwe jest wysyłanie wstępnie zserializowanego JSON przez PersistentConnection, czego nie można zrobić za pomocą hubów. W niektórych sytuacjach może to być istotna korzyść związana z wydajnością.

Oprócz tego zobacz cytat z dokumentacji :

Wybór modelu komunikacji

Większość aplikacji powinna korzystać z interfejsu API centrów. Interfejs API Connections może być używany w następujących okolicznościach:

  • Należy określić format wysyłanej wiadomości.

  • Deweloper woli pracować z modelem przesyłania wiadomości i wysyłania zamiast modelu zdalnego wywołania.

  • Istniejąca aplikacja korzystająca z modelu obsługi wiadomości jest przenoszona do korzystania z sygnalizującego.

W zależności od struktury wiadomości możesz również uzyskać niewielkie korzyści w zakresie wydajności dzięki użyciu PersistentConnection.

Możesz chcieć przyjrzeć się przykładom sygnalizującym, w szczególności tutaj.


Jeden z moich współpracowników powiedział mi, że powód, dla którego wybrał połączenie trwałe zamiast koncentratorów, to powód związany z bezpieczeństwem, czy jest jakiś problem z bezpieczeństwem w hubach czy coś?
Mehdi Dehghani

24

Istnieją dwa sposoby korzystania z SignalR: możesz uzyskać do niego dostęp na niskim poziomie, zastępując jego PersistentConnectionklasę, co daje dużą kontrolę nad nim; lub możesz pozwolić SignalR wykonać wszystkie ciężkie prace za Ciebie, używając „Hubów” wysokiego poziomu.


5

Trwałe połączenie to interfejs API niższego poziomu, możesz wykonywać akcje w bardziej określonym czasie, gdy połączenie jest otwierane lub zamykane, w większości aplikacji najlepszym wyborem jest Hub


4

Porównując te dwa elementy, należy wziąć pod uwagę trzy główne kwestie:

  • Format wiadomości
  • Model komunikacji
  • Dostosowywanie sygnalizującego

W przypadku centrów formatowanie wiadomości jest w zasadzie obsługiwane przez Ciebie, ale przy trwałych połączeniach wiadomość jest nieprzetworzona i jest tokenizowana i analizowana w tę iz powrotem. Jeśli rozmiar wiadomości jest ważny, należy również zauważyć, że ładunek trwałego połączenia jest znacznie mniejszy niż w przypadku koncentratora.

Jeśli chodzi o model komunikacji, trwałe połączenia mają w zasadzie funkcję wysyłania i odbierania wiadomości, podczas gdy koncentratory przyjmują model zdalnego wywoływania procedur z unikalną funkcją na żądanie.

Jeśli chodzi o dostosowywanie, ponieważ trwałe połączenia są niższego poziomu, mogą zapewnić większą kontrolę nad dostosowywaniem.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.