Переписывание проекта Silverlight в javascript, wcf участвует

Question

Существует проект C#, содержащий несколько сервисов wcf, включая basichttpbinding и nettcpbinding. И проект silverlight, потребляющий услуги. Для части nettcpbinding устанавливается соединение с сервером. Когда сервер получает новые данные в другом месте, он отправляет данные подключенным клиентам через канал обратного вызова.

О silverlight, я ничего не знаю, но он работает у клиента. Я думаю, что это важная вещь: поскольку sliverlight работает на клиенте и написан на C#, легко использовать wcf-сервисы, в том числе дуплексные.

Моя задача - переписать проект silverlight, в основном используя javascript. Для недуплексной части я написал несколько обработчиков ashx и вызывается с помощью ajax. (Правильно?)

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

Answer 1

Web sockets - новый стандарт HTML5, который поддерживает push от сервера к клиенту. (Фактически, сетевые сокеты, вероятно, превосходят дуплексные классы Silverlight, которые не используют истинный толчок под капотом, а скорее старомодный длинный опрос с периодическими «живыми» сигналами от клиента.)

Я бы предложите взглянуть на SignalR, который является компонентом ASP.Net, который обертывает функциональность веб-сокета, а также «возвращается к другим совместимым технологиям для старых браузеров».

Answer 2

Я был в аналогичной позиции пару лет назад: у меня был клиент Silverlight, говорящий с дуплексным WCF-сервером, который мне нужно было переносить в JavaScript/HTML5. Вопрос был: «Что мы делаем с бэкэндом?» Я остановился на том же сценарии, который описывает @McGarnagle, а именно, переключении на SignalR на бэкэнд и использовании JavaScript-клиента SignalR для связи с этим бэкэнд. Я мог бы потратить много времени на перестройку бэкэнда WCF для обмена логикой с SignalR, но поскольку мы фактически отказались от нашего клиента Silverlight, в итоге получилось более простое сокращение и вставка кода, приводящего сервис WCF в новые концентраторы SignalR ,

О единственном, что мне не понравилось с SignalR (в то время), является то, что он использовал только динамические объекты для связи с клиентом. Я предпочел (и продолжать предпочитаю) статическую проверку времени компиляции. Я думаю, что есть способы сделать это сейчас с SignalR и TypeScript, но я не исследовал их недавно.

Основной альтернативой, кстати, которую я исследовал, был JavaScript, чтобы поговорить с той же службой WCF. Хотя предположительно были некоторые способы заставить это работать, казалось, что они не очень зрелые и вряд ли будут хорошо поддерживаться в будущем. SignalR определенно является тем подходом, который вы хотите использовать, если вы пытаетесь использовать C# на сервере и JavaScript на клиенте и нуждаетесь в двусторонней связи: избегайте WCF в этом сценарии.