Типы повторного использования WCF в ссылочных сборках не используют повторно интерфейс ServiceContract

У меня есть четыре отдельных проекта:

  • MyUserControl. Требуется ссылка на службу, реализующую IMyService

  • MyService - реализует IMyService

  • MySharedInterfaces - содержит IMyUserControl и IMyService

  • MyWebApp

Пользовательский элемент управления должен быть динамически загружен во время выполнения. Это реализует IMyUserControl и имеет свойство типа IMyService, которое будет установлено во время выполнения.

Проблема с возможностью повторного использования типов, MyWebApp не использует повторно интерфейс IMyService. Он всегда генерирует его снова из справочника службы. Это не будет проблемой, если я могу применить его к MySharedInterfaces.IMyService, чего я не могу понять, так как он должен быть точно таким же.

Пользовательский элемент управления ожидает что-то типа IMyService. В любом случае, чтобы вернуть WebServiceReference.IMyService обратно в MySharedInterface.IMyService или заставить WebServiceReference повторно использовать MySharedInterface.IMyService?

ОТВЕТЫ

Ответ 1

Мэтт, вы, безусловно, можете сделать "двухэтапный" процесс создания прокси-сервера на стороне клиента - это действительно не biggie.

В своем клиентском приложении укажите ссылку MySharedInterfaces. Затем создайте экземпляр ChannelFactory<T> для вашего служебного интерфейса:

ChannelFactory<IMyService> factory = new ChannelFactory<IMyService>();

В основном это создает класс factory, который затем способен создавать фактические каналы связи между вашим клиентом и вашим сервером. Поскольку для этого требуется контракт на обслуживание, этот метод работает только в том случае, если вы можете совместно использовать сборку сервисного контракта (который вы можете и хотите в своем случае).

Это довольно затратный и ресурсосберегающий шаг, поэтому, если это вообще возможно, попробуйте где-то запереть factory и повторно использовать его, а не постоянно его воссоздавать.

Учитывая ваш канал factory, вы можете создавать свои реальные каналы связи, что в основном эквивалентно вашему прокси-клиенту, который генерируется с помощью Add Service Reference:

IMyService client = factory.CreateChannel();

Это не очень дорогостоящая операция, поэтому вы можете делать это каждый раз перед вызовом службы, а не беспокоиться о неисправных каналах и т.д.

client также реализует интерфейс ICommunicationObject, поэтому, если вам нужно проверить что-то связанное с WCF, например состояние канала, вы можете направить своего клиента:

CommunicationState currentState = ((ICommunicationObject)client).State;

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

Ответ 2

Включили ли вы ссылку на MySharedInterfaces в MyUserControl? Есть ли у MySharedInterfaces какие-либо ссылки на другие сборки, на которые не ссылаются в MyUserControl?

Жесткий путь не использует созданную ссылку на службу и использовать ChannelFactory. Это дает вам интерфейс от MySharedInterfaces.