SignalR: Tại sao chọn Hub so với kết nối liên tục?


150

Gần đây tôi đã tìm kiếm và đọc trên SignalR và, trong khi tôi thấy rất nhiều lời giải thích về sự khác biệt giữa Hub và Kết nối liên tục, tôi không thể hiểu được cấp độ tiếp theo, đó là lý do tại sao tôi Chọn một cách tiếp cận khác?

Câu trả lời:


92

Từ những gì tôi thấy trong phần Kết nối và Hub , có vẻ như Hub cung cấp một hệ thống chủ đề bao phủ các kết nối liên tục ở cấp độ thấp hơn.

Từ các bình luận được đánh giá cao dưới đây:

Một phần đúng. Bạn cũng có thể nhận được các chủ đề hoặc các nhóm trong các kết nối liên tục. Sự khác biệt lớn là gửi các loại tin nhắn khác nhau. Ví dụ: bạn có các loại tin nhắn khác nhau và bạn muốn gửi các loại tải trọng khác nhau. Với các kết nối liên tục, bạn phải nhúng loại thông báo trong tải trọng (xem Mẫu thô) nhưng các trung tâm cung cấp cho bạn khả năng thực hiện RPC qua kết nối (cho phép bạn gọi các phương thức trên máy khách từ máy chủ và từ máy chủ đến máy khách) . Một điều lớn nữa là mô hình ràng buộc. Hub cho phép bạn truyền các tham số được gõ mạnh cho các phương thức.

Ví dụ được sử dụng trong tài liệu sử dụng phép ẩn dụ của phòng trò chuyện, trong đó người dùng có thể tham gia một phòng cụ thể và sau đó chỉ nhận được tin nhắn từ những người dùng khác trong cùng một phòng. Nói chung, mã của bạn đăng ký vào một chủ đề và sau đó nhận được các tin nhắn được xuất bản cho chủ đề đó. Với các kết nối liên tục, bạn sẽ nhận được tất cả các tin nhắn.

Bạn có thể dễ dàng xây dựng hệ thống chủ đề của riêng mình trên đầu các kết nối liên tục, nhưng trong trường hợp này, nhóm SignalR đã làm việc cho bạn.


180
Một phần đúng. Bạn cũng có thể nhận được các chủ đề hoặc các nhóm trong các kết nối liên tục. Sự khác biệt lớn là gửi các loại tin nhắn khác nhau. Ví dụ: bạn có các loại tin nhắn khác nhau và bạn muốn gửi các loại tải trọng khác nhau. Với các kết nối liên tục, bạn phải nhúng loại thông báo trong tải trọng (xem Mẫu thô) nhưng các trung tâm cung cấp cho bạn khả năng thực hiện RPC qua kết nối (cho phép bạn gọi các phương thức trên máy khách từ máy chủ và từ máy chủ đến máy khách) . Một điều lớn nữa là mô hình ràng buộc. Hub cho phép bạn truyền các tham số được gõ mạnh cho các phương thức.
davidfowl

1
Điểm hay @davidfowl - Tôi đã sao chép bình luận của bạn vào câu trả lời vì tôi nghĩ nó nên nổi bật hơn.
ColinE

63

Sự khác biệt chính là bạn không thể thực hiện RPC với PersistentConnection, bạn chỉ có thể gửi dữ liệu thô. Vì vậy, thay vì gửi tin nhắn từ máy chủ như thế này

Clients.All.addNewMessageToPage(name, message);

bạn phải gửi một đối tượng với Connection.Broadcast()hoặc Connection.Send()sau đó khách hàng sẽ phải quyết định phải làm gì với điều đó. Bạn có thể, ví dụ, gửi một đối tượng như thế này:

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

Và trên máy khách, thay vì chỉ đơn giản là xác định

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

bạn phải thêm một cuộc gọi lại để xử lý tất cả các tin nhắn đến:

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

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

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

Bạn sẽ phải thực hiện cùng một loại công văn ở phía máy chủ trong OnReceived phương thức. Bạn cũng phải giải tuần tự hóa chuỗi dữ liệu ở đó thay vì nhận các đối tượng được gõ mạnh như bạn làm với các phương thức hub.

Không có nhiều lý do để chọn PersistentConnection trên Hub. Một lý do tôi biết là có thể gửi JSON được định sẵn thông qua PersistentConnection, mà bạn không thể sử dụng các hub. Trong một số tình huống, đây có thể là một lợi ích hiệu suất có liên quan.

Ngoài ra, xem trích dẫn này từ tài liệu :

Chọn mô hình truyền thông

Hầu hết các ứng dụng nên sử dụng API Hubs. API kết nối có thể được sử dụng trong các trường hợp sau:

  • Định dạng của tin nhắn thực tế gửi cần phải được chỉ định.

  • Nhà phát triển thích làm việc với một mô hình nhắn tin và gửi đi hơn là một mô hình gọi từ xa.

  • Một ứng dụng hiện có sử dụng mô hình nhắn tin đang được chuyển sang sử dụng SignalR.

Tùy thuộc vào cấu trúc thư của bạn, bạn cũng có thể nhận được những lợi ích nhỏ từ việc sử dụng PersistentConnection.

Bạn có thể muốn xem các mẫu SignalR, cụ thể là ở đây.


Một trong những đồng nghiệp của tôi đã nói với tôi lý do anh ấy chọn PersistentConnection over Hubs là lý do bảo mật, có vấn đề bảo mật nào trong Hub hay gì không?
Mehdi Dehghani

24

Có hai cách để sử dụng SignalR: bạn có thể truy cập nó ở mức thấp bằng cách ghi đè PersistentConnectionlớp của nó , điều này mang lại cho bạn nhiều quyền kiểm soát đối với nó; hoặc bạn có thể để SignalR thực hiện tất cả các công việc nặng nhọc cho bạn, bằng cách sử dụng 'Hubs' cấp cao.


5

Kết nối liên tục là API cấp thấp hơn, bạn có thể thực hiện các hành động vào thời gian cụ thể hơn khi kết nối được mở hoặc đóng, trong hầu hết các ứng dụng, Hub là lựa chọn tốt nhất


4

Có ba điểm chính cần xem xét khi so sánh hai điều này:

  • Định dạng tin nhắn
  • Mô hình truyền thông
  • Tùy chỉnh SignalR

Với định dạng tin nhắn trung tâm về cơ bản được xử lý từ bạn nhưng với các kết nối liên tục, tin nhắn là thô và đã được mã hóa và phân tích qua lại. Nếu kích thước thư là quan trọng thì cũng lưu ý rằng tải trọng của kết nối liên tục ít hơn nhiều so với trung tâm.

Khi nói đến mô hình truyền thông, các kết nối liên tục về cơ bản có chức năng gửi và nhận tin nhắn trong khi các trung tâm thực hiện cuộc gọi thủ tục từ xa mô hình với chức năng duy nhất theo yêu cầu.

Khi nói đến tùy chỉnh vì các kết nối liên tục ở mức thấp hơn, chúng có thể cho bạn quyền kiểm soát nhiều hơn đối với tùy chỉnh.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.