Динамический выбор типа путем проверки входящего JSON в WCF?

Question

У меня сложная иерархия объектов JSON, публикуемых в сервис WCF. По дизайну и другим требованиям каждый объект JSON имеет целочисленный идентификатор, концептуально представляющий его тип или макет поля (назовем его идентификатором типа).

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

Пример ввода:

{
 "typeId": 4,
 "someField1": "foo",
 "someField2": "bar",
 "otherObject": 
    {
     "typeId": 7
     "someField3": "abc",
     "someField4": "xyz"
    }
}

Пример (идеал) Процесс:

1. I receive partially parsed object.
2. I inspect "typeId" which has value 4.
3. I notify the deserialization process that I elect to use my .NET type FooBarA.
4. I receive partially parsed object.
5. I inspect "typeId" which has value 7.
6. I notify the deserialization process that I elect to use my .NET type FooBarB.

Это или подобное можно сделать? Кажется, я вспоминаю службы asmx-стиля, которые раньше включали поле __type, аналогичное моему типу id, я полагаю, но я не помню его точное назначение или возможность его включения в WCF в качестве альтернативы.

Answer 1

Вы можете собрать входящий JSON в виде строки (если вам нужен «конкретный» тип) или вы можете принять JSON в виде потока (очень полезно, если вы находитесь в сценарии на основе REST), а затем скопировать его вMemoryStream для обработки в несколько раз.Поскольку DataContractJsonSerializer работает с Stream, ваш лучший вариант использования - выгрузить его в MemoryStream.

Пример использования десериализации, который вы описываете, будет довольно трудным для выполнения, потому что если вложенный объект (в вашем случае"otherObject") не является членом родительского класса (в данном случае FooBarA), тогда процесс десериализации просто игнорирует значение, потому что ему некуда его поставить.

Переключение передач, более трудоемкоеВ процессе будет использоваться Json.Net, и вы сможете проходить через JSON в том же стиле, что и в Linq to XML.Преимущество Json.Net заключается в том, что он позволяет вам играть с JSON, который не обязательно идеально соответствует конкретным классам.Он не очень хорошо работает с WCF в цепочке сериализации, но я несколько раз использовал его на стороне WCF для работы с поставляемым JSON, который не совсем соответствует тому, что ищет конкретный класс.

Json.Net можно найти здесь - http://json.codeplex.com/