Читаю книжку про WCF.
Пишут, что ChannelFactory используется для создания прокси "на ходу".
Не возьму в толк, в чем отличие ChannelFactory от использования конструктора прокси класса?
Использование ChannelFactory как и явное использование конструктора требует указания типа интерфейса.
Параметры требуются одинаковые, что для ChannelFactory, что для конструктора прокси-класса.
Абстрактный класс ChannelFactory не предоставляет обобщенного методоа CreateChannel (требуется инстациировать шаблон типом интерфейса прежде чем его использовать), т.е. его нельзя использовать как абстрактную фабрику.
В чем прикол ChannelFactory? Какие у него преимущества перед явным конструированием прокси-объекта?
Здравствуйте, Rothmans, Вы писали:
R>В чем прикол ChannelFactory? Какие у него преимущества перед явным конструированием прокси-объекта?
В MSDN этот вопрос освещён скудно, и я могу ошибаться, но емнип ChannelFactory целесообразно использовать в том случае, если подлежащий протокол коммуникации поддерживает возможность постоянного соединения, например, HTTP 1.1. В этом случае все клиенты, порождаемые ChannelFactory, могут совместно использовать общее TCP/IP — соединение.
Здравствуйте, Rothmans, Вы писали:
R>Привет всем,
R>В чем прикол ChannelFactory? Какие у него преимущества перед явным конструированием прокси-объекта?
Я использую ChannelFactory в том случае, когда не хочется генерить промежуточные классы прокси. Возможно использовать одни и те же интерфесы клиента и сервера без генерации промежуточных классов. Примеров очень много в интернете. Вот нашел например вот здесь.
Здравствуйте, Rothmans, Вы писали:
R>Да, это и имеется в виду. По ссылке поучительно, но я делаю вывод, что с точки зрения чистой функциональности отличий нет.
Ну, как сказать. Proxy является оберткой над channel factory, которая предоставляет дополнительную функциональность из коробки. Если эта функциональность не нужна или вообще мешается, то большего контроля над поведением можно добиться используя ChannelFactory напрямую. Так что сказать, что с точки зрения чистой функциональности отличий нет — нельзя, proxy, как минимум, заниматется довольно интеллектуальным кешированием ChannelFactory, в зависимости от сценария использования.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Rothmans, Вы писали:
R>>Да, это и имеется в виду. По ссылке поучительно, но я делаю вывод, что с точки зрения чистой функциональности отличий нет. IB>Ну, как сказать. Proxy является оберткой над channel factory, которая предоставляет дополнительную функциональность из коробки. Если эта функциональность не нужна или вообще мешается, то большего контроля над поведением можно добиться используя ChannelFactory напрямую. Так что сказать, что с точки зрения чистой функциональности отличий нет — нельзя, proxy, как минимум, заниматется довольно интеллектуальным кешированием ChannelFactory, в зависимости от сценария использования.
Было бы здорово увидеть "правильный" пример использования ChannelFactory. А то я уже подозреваю что у нас он не кошерный, правда вопросы производительности при создании ChannelFactory миеня мало волнуют. Волнует скорее правильная работа с ресурсами.
наверное Правильно ли я понимаю что если мы создаём прокси налету например так:
public class SupervisorServiceClient
{
/// <summary>
/// Gets instance of ICatiConsoleWS web service.
/// </summary>public static ISupervisorService supervisorService
{
get
{
ChannelFactory<ISupervisorService> factory = new ChannelFactory<ISupervisorService>("SupervisorServiceEndpoint");
factory.Endpoint.Address = new EndpointAddress(factory.Endpoint.Address.Uri + BackendInstance.Current.Name);
return factory.CreateChannel();
}
}
}
То то, инстанс который возвращается методом CreateChannel надо закрывать кастя экземпляр к ICommunicationObject и вызывая Close? Чем может грозить не вызов Close?
Здравствуйте, Tom, Вы писали:
Tom>То то, инстанс который возвращается методом CreateChannel надо закрывать кастя экземпляр к ICommunicationObject и вызывая Close? Чем может грозить не вызов Close?
Исчерпанием лимита соединений.
Лечится установкой атрибутов элемента конфигурации serviceThrottling в запредельные значения.
Здравствуйте, Tom, Вы писали:
Tom>То то, инстанс который возвращается методом CreateChannel надо закрывать кастя экземпляр к ICommunicationObject и вызывая Close?
Да.
Tom>Чем может грозить не вызов Close?
Соединение будет болтаться открытым и не вернется в пул.
Мы уже победили, просто это еще не так заметно...
Правильно ли я понимаю что если мы создаём прокси налету например так: