У меня проблема с WCF. Я думаю, что понимаю, в чем проблема, но мне нужно
проверить это понимание и спросить, видел ли кто-нибудь это раньше или может предложить
Обходной путь или альтернативный подход. Пожалуйста, потерпите меня: это значительный
проблема, которую трудно разобрать до минимального контрольного примера.
Проблема: я пишу интерфейс C # для устаревшей системы обмена сообщениями. я имею
реализована сборка взаимодействия для прямого интерфейса, и все работает нормально.
Основой этого является то, что у меня есть класс для каждого типа сообщения, и универсальный класс
для передачи, которая просто занимает то же место, что и сообщение максимального размера.
Каждый класс сообщений реализует операторы приведения для приведения и выхода из этого
универсальный класс, называемый QOD_Message. Общий класс и индивидуальное сообщение
оба класса являются производными от минимального класса сообщений без тела. Клиентское приложение на C #
желая отправить сообщение, просто вызывает метод send в сборке интерфейса, которая
принимает QOD_Message, приведя к универсальному типу для отправки. Событие получателя
передает получающему приложению C # универсальный тип, который приводится в соответствии с общим
член, имеющий отношение один к одному с типом сообщения.
Я реализовал локальную прямую сборку интерфейса, и все это прекрасно работает
и теперь я могу сообщение между тестовым приложением C # и существующим собственным наследием
Приложения. Замечательно. Основная структура класса выглядит следующим образом:
public class QOD_Message_Minimal
{
a message header
}
public class QOD_Message : QOD_Message_Minimal
{
generic message - defines an empty body
}
public class QOD_WcfDialout : QOD_Message_Minimal
{
... some irrelevant code
// cast operators to convert to and from the abstract message class.
public static implicit operator QOD_Message (QOD_WcfDialout m)
{
... some irrelevant code
}
public static implicit operator QOD_WcfDialout (QOD_Message m)
{
... some irrelevant code
}
}
Обратите внимание на операторы приведения.
Теперь приходит проблема. Я хочу расширить этот интерфейс для поддержки WCF, поэтому
другая группа разработчиков за рубежом может общаться через WCF с адаптером
Сервис WCF я написал. Это называется, с замечательным отсутствием
воображение, WCF_Adapter. WCF_Adapter предоставляет для целей тестирования
единственный метод, который принимает строку (Dialout) и преобразует ее в сообщение для
старый код Это также работает нормально, с вызовом функции в моем
Приложение WCF_Client преобразуется в устаревшее сообщение и отправляется
(фиксированный) получатель.
Поэтому я попытался расширить интерфейс, чтобы добавить точку входа, которая бы принимала
QOD_Message (Dispatch), в надежде, что это будет работать так же, как прямой
интерфейс, то есть отправитель бросил бы свое сообщение в QOD_Message, вызов
функция отправки с этим типом, и адаптер будет просто передавать
получил общее сообщение в свою локальную сборку интерфейса для дальнейшего
отправка. Таким образом, код WCF будет выглядеть почти так же, как обычный обмен сообщениями
Код.
[ServiceContract]
public interface IDialout
{
[OperationContract (IsOneWay = true)]
void Dialout (string NumberToDial);
[OperationContract (IsOneWay = true)]
void Dispatch (QOD_Message msg);
}
Поэтому я расширил клиент и службу WCF_adapter, сгенерировав
мой прокси-код для клиента WCF и .... о. Клиент не будет компилироваться.
Кажется, что клиентское приложение не может понять оператор приведения и выдает
ошибка компиляции. Даже если я включу сборку сообщений с кодом выше
в качестве ссылки, клиентский код «предпочитает» тип, определенный в сгенерированном
прокси и игнорирует исходный тип сообщения, поэтому он не может "видеть" приведение и
не скомпилируется. Это ошибка:
предупреждение CS0436:
Тип «QOD_Messaging.QOD_Message» в «бла-бла \ генерируемый прокси.cs»
конфликтует с импортированным типом 'QOD_Messaging.QOD_Message' в
"Бла-бла \ QOD_Messaging.dll. Использование типа, определенного в «blah-blah \ генерируемое Proxy.cs».
Насколько я могу судить, класс, определенный в сгенерированном прокси, правильный,
но, конечно, сгенерированный прокси-класс определяет только элементы данных, а не функциональность.
Содержит два класса
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="QOD_Message_Minimal", Namespace="http://schemas.datacontract.org/2004/07/QOD_Messaging")]
[System.Runtime.Serialization.KnownTypeAttribute(typeof(QOD_Messaging.QOD_Message))]
public partial class QOD_Message_Minimal : object, System.Runtime.Serialization.IExtensibleDataObject
{
whole slew of data members.
}
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="QOD_Message", Namespace="http://schemas.datacontract.org/2004/07/QOD_Messaging")]
public partial class QOD_Message : QOD_Messaging.QOD_Message_Minimal
{
extra stuff to define the added body.
}
Так .....
Я могу не указывать ссылку на сборку, поэтому код не может видеть приведение и не работает
скомпилировать, или я могу оставить ссылку в и компилятор умышленно игнорирует
определение типа сборки и использует определение прокси ... и не компилируется.
Другие разработчики WCF видели подобные вещи раньше? Или все придерживаютсяпростых параметров значения при вызове конечных точек WCF? Должен ли я просто
объявить конечную точку с уникальным параметром класса для каждого вида сообщения I
может захотеть отправить? Это кошмар обслуживания.