Почему важно удалить / закрыть клиентский прокси WCF - PullRequest
Новая
       44

Почему важно удалить / закрыть клиентский прокси WCF

9 голосов
/ 25 августа 2011

Я слышал, что важно удалить (или закрыть) клиентский прокси WCF, даже если

  • вы не используете сеансы
  • нет неуправляемых ресурсов, которые требуют детерминированной очистки (например, открытые сокеты)

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

var clt = new MyServiceClient();
clt.PlaceOrder(foo);
// no dispose

или 

var clt = new ChannelFactory<IOrderService>().CreateChannel();
clt.PlaceOrder(foo);

Спасибо

Ответы [ 3 ]

15 голосов
/ 25 августа 2011

Хорошо практиковать закрывать вещи (и распоряжаться ими), когда вы закончите с ними. (Не могли бы вы оставить поток файлов открытым, даже если вы читаете / пишете в него / из него?) От руки я вижу несколько причин:

  1. Сервер (может / будет) имеет ограниченное количество активных соединений, которые он поддерживает. Чем раньше вы избавитесь от своей услуги, тем скорее следующий клиент сможет использовать этот слот. (Зачем ждать тайм-аут, если вы на самом деле через?)
  2. Избегайте лишних накладных расходов неактивного соединения. В наши дни выделенные ресурсы «обильны», но чем меньше накладных расходов вы сохраняете, тем выше будет ваша производительность.
  3. Вы уменьшаете риск ошибок / исключений из-за тайм-аута, выбрасывая клиента по окончании.
  4. Закрывая его по окончании, вы фактически сохраняете чистоту журналов сервера. В конце концов, даже если клиент не показывает его, сервер может получить исключение тайм-аута, отображаемое в журнале из-за неактивных соединений, о которых не заботились, когда они должны были быть.
  5. MSDN сообщает (обратите внимание на 4-ую отметку в списке клиентских объектов WCF).

Лишь несколько причин, по которым я могу придумать, вне головы.

4 голосов
/ 25 августа 2011

Создание ChannelFactory & Открытие - это дорогостоящая операция, и вы должны избегать ее при каждом вызове, если вам нужна производительность.

Ваш первый вариант использования неверен даже с basicHttpBinding, потому что он потенциально может создать новую фабрику каналов для каждого экземпляра.В .NET 3.5 с пакетом обновления 1 (SP1) введено некоторое кэширование ChannelFactory, поэтому в некоторых сценариях вы можете быть в порядке.

Во втором случае использования, если вы кешируете и повторно используете фабрику каналов, удаление не является действительно необходимым, но имейте в виду, что вы / вашпарень по развертыванию может изменить время привязки @ развертывания, и отсутствие закрытия / удаления может оказать огромное влияние.

Таким образом, всегда безопасно закрывать / утилизировать, и поэтому MSDN рекомендует это.

2 голосов
/ 25 августа 2011

Это действительно зависит от типа клиента. Например, если вы пишете приложение ASP.NET, которое вызывает службу, рекомендуется кэшировать прокси, поскольку его создание стоит дорого.

При этом, как только вы закончили работу с любым IDisposable-ресурсом, вы должны утилизировать его, чтобы у удаляемого объекта была возможность высвободить ресурсы, за которые он держится, чтобы его можно было удалить из памяти. Если объект IDisposable имеет метод Close, он должен быть вызван первым.

Отличная статья на эту увлекательную тему можно найти здесь: http://msdn.microsoft.com/en-us/magazine/bb985010.aspx

...