Silverlight 4.0 и клиентский прокси-сервер WCF - как создавать и как закрывать экземпляры
Тема жизненного цикла прокси-сервера Silverlight WCF мне не очень ясна. Я прочитал здесь различные материалы, ресурсы, ответы, но все же не совсем понимаю предполагаемый лучший способ их использования.
В настоящее время я использую настраиваемую двоичную привязку в Silverlight 4.0.
Создается ли прокси в silverlight дорогая операция? Стоит ли пытаться поделиться экземпляром прокси в коде или лучше создать новый? Должны ли мы делать блокировку, если мы делимся, если к ней обращаются несколько потоков?
Поскольку ошибка на прокси-сервере приведет к ошибке его состояния, я думаю, что совместное использование прокси - не лучшая идея, но я читал, что создание прокси стоит дорого, поэтому не совсем понятно, что здесь делать.
А с закрытием - клиенты службы Silverlight WCF предоставляют только метод CloseAsync. Также прокси-серверы требуют использования определенной логики, когда они закрываются (если они неисправны, мы должны вызвать Abort (), который является синхронным в Silverlight, а если нет, мы должны CloseAsync, который не является синхронным или что?).
Во многих официальных Silverlight образцы из прокси MS не закрываются вообще, это просто недостаток материалов или ожидаемый подход к ним?
Тема очень важна для меня, и я хочу четкое понимание всех вещей, которые следует учитывать, чего у меня сейчас нет .
(Я действительно видел, что этот вопрос Каков надлежащий жизненный цикл прокси-сервера службы WCF в Silverlight 3? кажется мне близким к моему, но я не могу сказать, что удовлетворен качеством ответов)
Мне бы очень хотелось увидеть пример кода, который использует, создает, закрывает и т. Д. WCF-прокси, и, самое главное, объясняет, почему это лучший из возможных способов. Я также думаю (в настоящее время считаю), что из-за характера проблемы должен существовать единый общий подход / шаблон - подход к использованию (созданию, повторному использованию, закрытию) прокси WCF в Silverlight.
1 ответ
Создание прокси-сервера не дорого по сравнению с передачей в оба конца. Я видел комментарий, в котором говорится о вызове CloseAsync сразу после ваших вызовов других асинхронных методов, но это, похоже, некорректно. В теории закрытие переходит в состояние ожидания и происходит после того, как другие ваши асинхронные вызовы заканчиваются. На практике я видел, как вызовы неожиданно быстро заканчиваются ошибкой, а затем сам отказывает CloseAsync, потому что канал уже вышел из строя.
Что я сделал, так это создал универсальный класс Caller<TResult>, который имеет несколько перегрузок универсального метода CallAsync, которые принимают аргументы и обратный вызов типа Action<TResult>. Под прикрытием Caller будет связывать событие XxxCompleted и проверять, была ли причина завершения причиной ошибки или нет. В случае ошибки это будет Abort канал. Если нет ошибки, он вызвал бы CloseAsync и затем вызвал бы обратный вызов. Это предотвращает «глупые» ошибки, такие как попытка использовать канал в неисправном состоянии.
Все вышеизложенное предполагает модель create-proxy-make-call-discard-use-proxy. Если вам нужно было сделать много вызовов в быстрой последовательности, вы могли бы адаптировать этот подход для подсчета количества вызовов в полете, а после завершения последнего выполните закрытие или прерывание.
Вероятно, будут редкими проблемы, связанные с созданием прокси для каждого вызова или набора связанных вызовов. Только если накладные расходы слишком высоки, я буду использовать прокси-кэширование или стратегию повторного использования. Помните, что чем дольше вы держите ресурс, тем больше вероятность отказа. По моему опыту, по крайней мере, чем меньше срок службы, тем лучше воспринимаемая пользователем производительность, потому что вы меньше его прерываете, вам не нужно дорого поддерживать логику повторения (или, по крайней мере, меньше это), и вы более уверены, что не теряете память или ресурсы, точно зная, когда от них избавиться.
Что касается вашего вопроса о том, что примеры не закрываются ... ну, это примеры, и они, как правило, одномерные и неполные, потому что они иллюстрируют общее использование, а не все особенности того, что вам нужно делать в целом время жизни приложения.