WCF-это плохая практика оставлять канал открытым долгое время?
Я просто изучаю веревки вокруг WCF. Я планировал открыть дуплексный канал между клиентом и сервером с помощью NetTcpBinding и держать его открытым неопределенно долго, чтобы сервер мог инициировать запросы к клиенту.
затем я наткнулся на этот блог Джесси Эзелла, что, похоже, указывает на то, что плохо держать канал открытым бесконечно, потому что вы не можете поймать ошибки, и это вызывает всевозможные нестабильности.
Это правильно? Если я использую NetTcpBinding и сохраняю ссылку на открытый канал по обе стороны отношений, что произойдет, если произойдет сбой связи? Как я могу поймать событие отказа? Какие еще есть готы? Есть ли разница, какую .NET framework вы используете? (Я на 4.0.)
2 ответов
Я не согласен с Джесси (в качестве примечания: он также рекомендует использовать классы служб WCF в качестве синглетов по умолчанию, что является худшей идеей когда-либо на мой взгляд).....
пока вы хорошо заботитесь о ловле исключений на сервере (например, путем реализации IErrorHandler интерфейс в вашем классе обслуживания), здесь нет смысла продолжать выключать ваш канал... особенно в корпоративной среде LAN с использованием netTcpBinding.
Да, это хорошая практика, чтобы закрыть канал, Как только он не нужен больше. Но это необычно в случае дуплексной связи. При использовании дуплексной связи необходимо Открыть канал, чтобы сервер мог отправлять сообщения клиенту. Связь WCF всегда инициируется клиентом. Обратный вызов разрешен только при сохранении канала, инициированного клиентом, открытым.
дуплексная связь включает в себя некоторые дополнительные задачи для обработки ошибок связи. Ваш служба должна содержать некоторый механизм ping, позволяющий клиенту проверять соединение через регулярный интервал. Если соединение не удается, клиент получает исключение, и вы сможете восстановить соединение. Также служба должна обрабатывать исключение при отправке сообщения обратного вызова на неисправный канал.