отправка запроса с универсальным типом данных из FlashBuilder4 в сервис wcf - PullRequest
1 голос
/ 02 марта 2011

У меня настроен сервис wcf на сервере, который поставляет данные в проект flex, созданный с использованием Flashbuilder4.Я использовал функцию самоанализа webservice для генерации DTO и прокси сервисов.У одного из DTO есть свойство типа Object.Содержимое этого общего объекта будет меняться в зависимости от определенных условий, но всегда будет другим сложным объектом.Создание и заполнение vo в FB4 проходит гладко, но когда объект сериализуется, он выглядит следующим образом:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<SOAP-ENV:Body> 
<tns:GetC xmlns:tns="EP2ProblemDemo1"> 
<tns:anyObj> 
<tns:Property1>yo!</tns:Property1> 
<tns:Property2>yo! yo!</tns:Property2> 
</tns:anyObj> 
</tns:GetC> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

Где вы можете заметить, что свойство anyObj пропускает какую-либо информацию о типе, несмотря на ссылку на объект типа ClassB:

public class ClassA
{
    public string Property1;
}
public class ClassB : ClassA
{
    public string Property2;
}

В аргументе anyObj для GetC отсутствует что-то вроде следующего:

xsi: type = "tns: ClassB" xmlns: tns = "EP2ProblemDemo1"

Что, в свою очередь, приводит к ошибке, когда служба wcf пытается декодировать сообщение.Я думаю, что служба интерпретирует содержимое anyObj как массив, который не может быть неявно преобразован в базовый объект?

При установке аргумента anyObj (типа Object) для экземпляра ClassB кажется, что информация о типепотерян.Это правильное поведение?У меня сложилось впечатление, что даже если вы можете установить переменную суперкласса для ссылки на один из ее подклассов, информация о типе подкласса должна быть сохранена и, следовательно, также включена в сериализованное представление этого объекта.

EDIT Кажется, что сериализатор FlashBuilder4 удаляет конкретный тип и информацию о пространстве имен из свойства типа Object при отправке обратно в службу wcf, которая затем не может десериализовать то, что выглядит как массив.Кроме того, при импорте файла WSDL в FB4 наследование VO теряется, поскольку они в конечном итоге расширяют EventDispatcher для возможности привязки.

РЕШЕНИЕ Мое решение состояло в том, чтобы изменить тактику и перейти к удаленному взаимодействию с AMF., реализованный в .NET с использованием FluorineFX Официальный сайт FluorineFX , который прекрасно работает и имеет приятный побочный эффект - более низкое потребление полосы пропускания благодаря передаче данных в виде байтового массива.

Я считаю, что WebORB Официальный сайт WebORB также может быть использован для реализации AMF в .net, но я еще не пробовал.

Ответы [ 2 ]

0 голосов
/ 02 марта 2011
  1. Для всех типов объектов, которые вы отправляете по сети, вам нужно установить атрибут с именем [DataContract]

    [DataContract] публичный класс ClassA { публичная строка Property1; }

  2. Вместо использования базового типа (объекта) вы должны использовать базовый класс и использовать атрибут [KnownType]

    [ServiceContract (Namespace = "EP2ProblemDemo1")] открытый интерфейс IService { [OperationContract] ClassC GetC (ClassD classB); }

    [KnownType (typeof (ClassA)), KnownType (typeof (ClassB))] открытый класс ClassD { }

Надеюсь, это поможет

0 голосов
/ 02 марта 2011

Вы не можете использовать «любой» объект. Вы должны всегда явно описывать, какие типы разрешены. Проверьте KnownTypeAttribute и ServiceKnownTypeAttribute или DataContractResolver (у меня пока нет большого опыта работы с этим). Если вам действительно нужно отправить произвольные данные и вы не можете определить все возможные объекты заранее, используйте вместо этого XElement. В xsd это будет описано как xsd: any.

...