статический объект класса прокси WCF

Question

1. У меня есть приложение WCF на основе привязки NetTCP.В клиентском приложении я создал объект прокси-класса как статический.Это клиентское приложение может работать в течение 4-8 часов после развертывания.В основном в окне входа в систему я создаю и инициализирую прокси-класс DataServiceClient (в основном, вставку и обновление базы данных) и использую один и тот же объект во всем приложении, пока пользователь не закроет главное окно.Есть ли какой-либо неблагоприятный эффект (с точки зрения производительности) создания статического объекта прокси-класса?Если да, то как мне этого избежать.Перед использованием статического объекта я создавал отдельный объект в каждом окне (где бы это ни требовалось), но это увеличивало время загрузки окна.

2. Как я могу улучшить производительность WCF.Я доволен его работой, но это может быть моей иллюзией.

Answer 1

1. Нет ничего плохого в использовании того же экземпляра, но убедитесь, что ваша обработка ошибок хороша.В противном случае прокси-объект перейдет в состояние ошибки, когда произойдет ошибка, и вам придется перезапустить все приложение.Есть некоторые события, к которым вы можете присоединиться при изменении состояния.После того, как прокси-объект переходит в сбойное состояние, вы должны создать новый, восстановить поврежденный прокси-объект невозможно.

2. Я обнаружил, что использование заголовков сообщений уменьшает количествометодов, которые мне действительно нужны, но это зависит от того, что делает ваш сервис.В противном случае я бы рекомендовал использовать потоковую передачу, когда это возможно.Держите ваши данные как можно меньше.Используйте двоичный форматер.

Answer 2

Похоже, ваш клиент является приложением Windows Forms - статический прокси-сервер службы должен быть в порядке, если вы не выполняете многопоточность или обратные вызовы для вашего прокси и т. Д. синхронизировать доступ к статическим переменным.

Говоря в общих чертах, производительность WCF может быть улучшена

1. Тщательно составляя контракт на обслуживание - он должен быть коренастым, а не болтливым, чтобы количество обращений в сервис уменьшалось
2. Выбор подходящей привязки - привязка TCP будет быстрее, чем привязка HTTP, но она будет соответствовать .NET и может не работать через Интернет, поскольку другие порты будут заблокированы. Если вы общаетесь на одной и той же машине, то именованная привязка по каналу будет самым быстрым режимом