Перенаправить данные клиенту с помощью SignalR vs WCF?

У меня есть одно клиентское приложение WPF. Теперь у меня есть сценарий, как клиент будет подключаться к серверу, и сервер будет периодически передавать данные клиенту. Я немного смущен тем, какие технологии и способы я должен выбрать для уведомления клиентов.

SignalR лучше всего подходит для веб-приложений, я думаю, и у меня есть настольное приложение. С помощью службы WCF мы можем реализовать push-уведомление через Duplex-канал и обратный вызов. Можете ли вы, пожалуйста, направить меня, какие достоинства и недостатки в использовании служб SignalR или WCF?

Спасибо

Ответы

Ответ 1

Ниже приведены мои наблюдения из опыта:

Преимущества SignalR:

  • Простота запуска, более низкая кривая обучения. Вы можете легко запустить пример из веб-страницы
  • Обработка исключений (например, падение соединения, тайм-ауты) встроена в API

SignalR cons:

  • Поддерживать только протокол HTTP

Duplex pros:

  • Поддерживает TCP в дополнение к HTTP. Это может серьезно повысить производительность, если вы знаете свои типы клиентов, и ваша система работает в закрытой сети. Кроме того, работа над TCP добавляет больше стабильности соединения, чем HTTP

Дуплексные минусы:

  • Высшая кривая обучения - сложнее запускать и иметь стабильное решение. Хотите проверить? Загрузите дуплекс и образец SignalR из Интернета и посмотрите, сколько времени вы потратите, чтобы успешно запускать друг друга.
  • Вам необходимо обработать все исключительные случаи (сбой подключения, тайм-ауты и т.д.).
  • Я знаю, что я не единственный, кто столкнулся с серьезными проблемами с тайм-аутом, когда вы хотите использовать дуплекс-сервис в течение длительного времени. Мы должны периодически звонить службам, чтобы поддерживать клиентские подключения.

Кстати, существуют API-интерфейсы для проектов JavaScript, Desktop и Silverlight для использования служб SignalR.

Ответ 2

SignalR - это не только веб. Серверный код сервера SignalR не заботится о технологии своих клиентов, вам просто нужно иметь разработчиков на стороне клиента.

Если мы изолируем передачу данных клиенту, я бы настоятельно рекомендовал SignalR, поскольку он намного проще, чем WCF в этом аспекте, у меня была своя доля проблем с WCF, и я думаю, у вас были некоторые. Я нашел простой пример консоли/веб-приложения здесь.

В общем, Duplex WCF и использование обратного вызова, такого как здесь, кажется мне очень грязным, есть много серверов сервера конфигурации, и именно поэтому Я думаю, что SignalR проще.

Кроме того, вы не можете использовать дуплекс (AFAIK) с javascript и objective-c.

Ответ 3

Думаю, у вас уже есть много данных о каждом из них. Но выбор SignalR предоставит вам дополнительное преимущество перед усилиями разработчиков, которые в большинстве случаев являются основным блоком принятия решения при выборе технологии.

Вам не нужно беспокоиться о разработке/тестировании API и т.д. и можете сосредоточиться на собственной реализации проекта.

Надеюсь, что это поможет!

Ответ 4

SignalR можно легко использовать теперь с несколькими клиентами из javascript,.NET и WinForms и WPF, и может даже использоваться с клиентом С++; Использование автономного сервера .NET signalr (OWIN) - действительно хороший способ иметь автономный сервер, который подталкивает/принимает/передает несколько клиентов. Единственное, что может быть проще, - это ZeroMQ, используя свою методологию публикации подписки.

Ответ 5

Один момент, который никто не поднял до сих пор:

  • SignalR 1.0.1 требует .NET 4 на сервере и клиенте. В зависимости от версию вашего клиента и сервера, на которые вы нацеливаете может быть важным фактором для рассмотрения.

Если вы просто хотите периодически обновлять новые данные, вам может быть лучше просто использовать WCF и механизм опроса со стороны клиента, а не использовать дуплексный WCF или signalr.