Нулевые значения для свойств объекта десериализованы WCF - PullRequest
Новая
       4

Нулевые значения для свойств объекта десериализованы WCF

7 голосов
/ 02 мая 2011

У меня есть веб-сервис WCF, который использовал для нормальной работы. Где-то вниз по линии это прекратилось, и я не могу сказать, почему. Код и интерфейс никогда не менялись, равно как и web.config (по крайней мере, в отношении раздела веб-сервисов). У меня есть класс: 

[DataContract]
public class QuizServiceArgs
{
    [DataMember(IsRequired = true, Order = 1)] 
    public int Category1 { get; set; }

    [DataMember(IsRequired = true, Order = 2)] 
    public int Category2 { get; set; }

    [DataMember(IsRequired = true, Order = 3)] 
    public int Category3 { get; set; }

    [DataMember(IsRequired = true, Order = 4)] 
    public int Category4 { get; set; }
}

А интерфейс сервиса прост: 

public interface IQuizService
{
    [OperationContract]
    [WebInvoke(Method = "POST",
       BodyStyle = WebMessageBodyStyle.WrappedRequest,
       ResponseFormat = WebMessageFormat.Json)]
    ServiceResult Save(QuizServiceArgs answers, string strvalue, int intvalue);
}

Вторые два параметра strvalue и intvalue были добавлены только для устранения неполадок, чтобы увидеть, были ли они десериализованы - и они есть. Когда я подключаюсь к сервису, я получаю сообщение о том, что в запросе отсутствует параметр Category1, но, как видно на снимке экрана Fiddler, значения есть.

fiddler screenshot

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

UPDATE

На самом деле я так и не получил ответ на свой первоначальный вопрос, который отстой, но Сиксто предложил переключить сериализацию на JSON. JSON был оригинальным дизайном, но получил, когда у меня возникли проблемы с ним. После того, как я успешно переключился обратно на JSON, все было правильно сериализовано и десериализовано. Сейчас я просто жду, пока это не прекратится без объяснения причин, чтобы я мог вернуться к XML ....

Ответы [ 2 ]

8 голосов
/ 02 мая 2011

У вас проблема с пространством имен.По умолчанию, когда вы создаете интерфейс для servicecontract, он назначает ему пространство имен.Пространство имен похоже на область действия для элементов SOAP xml, и если оно не попадает в ту же область, оно думает, что его не существует.Скорее всего, это код, который прервал сообщения, предоставляя пространство имен (?).Вы должны ссылаться на него при публикации XML - но я не совсем уверен, что он назначает (что-то специфичное для сервера), поэтому рекомендуется всегда определять пространство имен, например: 


[ServiceContract(Namespace = "your namespace")]
public interface IQuizService 
{     
     [OperationContract]     
     [WebInvoke(Method = "POST",        
            BodyStyle = WebMessageBodyStyle.WrappedRequest,        
            ResponseFormat = WebMessageFormat.Json)]     
            ServiceResult Save(QuizServiceArgs answers, string strvalue, 
                int intvalue); 
}

И тогда посты должны иметь пространство имен в запросе SOAP. 


<Save xmlns="your namespace">.....</Save>

Пространство имен также должно соответствовать объявлению вашей службы в web.config.

Также оно должно быть указано в datacontract

[DataContract(Namespace = "your namespace")]

5 голосов
/ 02 мая 2011

Атрибут DataMember IsRequired сообщает десериализатору WCF об ожидаемом элементе в XML-сообщении с таким именем (по крайней мере, для десериализации мыла).Похоже, клиентский код, который генерирует запрос сообщения, больше не отправляет все элементы Category ....Это не означает, что вы не можете отправить нулевое значение для объекта DataMember, помеченного IsRequired, это просто означает, что элемент должен существовать в сообщении.

ОБНОВЛЕНИЕ: более внимательный взгляд на XML, не долженбыть элементом QuizServiceArgs в XML?

...