Лучшая практика в течение Сервисного времени жизни Прокси WCF?
Вы можете взглянуть на эту презентацию на Java Forum в Штутгарте Германия в 2016 году.
Только несколько слайдов используют немецкий язык, 99% содержимого «Исходный код Java на английском языке»; например
someCollection.sort(
OurCustomComparator
.comparing(Person::getName)
.thenComparing(Person::getId)
);
, где OurCustomComparator использует методы по умолчанию (и другие интересные идеи). Как показано, приводя к очень сжатому коду, чтобы выбрать некоторый метод getter для сортировки; и супер простое соединение (или реверсирование) критериев сортировки.
Если вы находитесь в java8, вы найдете много материала, чтобы вы начали.
4 ответа
в дополнение к вещам Парень Старбак упомянул, что ключевой фактор будет моделью обеспечения безопасности, которую Вы используете (в сочетании с требованиями сессии) - если Вы не снова используете свой прокси, Вы не можете снова использовать безопасность сессии.
Это означает, что клиент должен был бы аутентифицировать себя с каждым вызовом, который расточителен.
, Если, однако, Вы решаете, это - то, что Вы хотите сделать, удостоверьтесь, что настроили клиент для не установления контекста защиты (поскольку Вы никогда не будете использовать его), это сохранит Вас несколько распространений в прямом и обратном направлениях к серверу:-)
Существует заключение здесь к Серверу Активированные Объекты в Дистанционной работе.NET (одна из технологий, которая заменяется WCF), которые имеют два режима, "Единственный Вызов", (не сохраняющий состояние) и "Singleton" (с сохранением информации).
подход, который Вы проявляете в WCF, должен быть основан на Вашей производительности и масштабирующихся требованиях в сочетании с потребностями Ваших потребителей, а также конструктивных ограничениях серверной стороны.
, Если необходимо поддержать состояние между вызовами к сервису, затем Вы, очевидно, захотите иметь экземпляр с сохранением информации, но если Вы не делаете необходимо, вероятно, реализовать его так, чтобы это было статично, который должен масштабироваться лучше (можно более легко загрузить баланс, и т.д.).
One more point to consider is channel faults. By design WCF does not allow to use client proxy after unhandled exception happened.
IMyContract proxy = new MyContractClient( );
try
{
proxy.MyMethod( );
}
catch
{}
//Throws CommunicationObjectFaultedException
proxy.MyMethod( );
Или лучше создать его и использовать повторно?
Не начинайте реализацию своей собственной реализации пула. Это уже было сделано в рамках. Прокси-сервер WCF использует фабрики кэшированных каналов внизу. Следовательно, создание новых прокси не слишком дорого (но см. Ответ Гая Старбака относительно сеансов и безопасности!).
Также имейте в виду, что время ожидания прокси-сервера истекает через определенное время простоя (10 минут по умолчанию).
Если вы хотите более явный контроль, вы можете рассмотреть возможность использования ChannelFactories и каналов напрямую вместо прокси-серверов ClientBase, которые «легко использовать, полностью из коробки».
http://msdn.microsoft.com/en-us/library/ms734681.aspx
Обязательно прочтите по этой теме: http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx