blocks|key|3068119|text|你可以正常地调用异步方法，你的执行将被简单地挂起，直到方法返回，你可以以标准的方式返回模型。就像这样打个电话：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3068120|string+jsonContent+=+await+actionContext.Request.Content.ReadAsStringAsync();|code-block|syntax|javascript|3068121|它将为您提供原始的JSON。|3068122|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

You can call async methods normally, your execution will be simply suspended until the method returns and you can return the model in standard manner. Just make a call like this:

<pre><code>string jsonContent = await actionContext.Request.Content.ReadAsStringAsync();
</code></pre>

It will give you raw JSON.

blocks|key|3068162|text|您不需要自定义模型绑定器。您也不需要在请求流水线上胡乱操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3068163|看看另一个SO：How+to+implement+custom+JsonConverter+in+JSON.NET+to+deserialize+a+List+of+base+class+objects?。|offset|length|3068164|我将此作为我自己解决相同问题的基础。|3068165|从SO中引用的JsonCreationConverter<T>开始(稍微修改一下，以修复响应中类型序列化的问题)：|style|CODE|3068166|public+abstract+class+JsonCreationConverter<T>+:+JsonConverter
{
++++///+<summary>
++++///+this+is+very+important,+otherwise+serialization+breaks!
++++///+</summary>
++++public+override+bool+CanWrite
++++{
++++++++get
++++++++{
++++++++++++return+false;
++++++++}
++++}
++++///+<summary>+
++++///+Create+an+instance+of+objectType,+based+properties+in+the+JSON+object+
++++///+</summary>+
++++///+<param+name="objectType">type+of+object+expected</param>+
++++///+<param+name="jObject">contents+of+JSON+object+that+will+be+
++++///+deserialized</param>+
++++///+<returns></returns>+
++++protected+abstract+T+Create(Type+objectType,+JObject+jObject);

++++public+override+bool+CanConvert(Type+objectType)
++++{
++++++++return+typeof(T).IsAssignableFrom(objectType);
++++}

++++public+override+object+ReadJson(JsonReader+reader,+Type+objectType,
++++++object+existingValue,+JsonSerializer+serializer)
++++{
++++++++if+(reader.TokenType+==+JsonToken.Null)
++++++++++++return+null;
++++++++//+Load+JObject+from+stream+
++++++++JObject+jObject+=+JObject.Load(reader);

++++++++//+Create+target+object+based+on+JObject+
++++++++T+target+=+Create(objectType,+jObject);

++++++++//+Populate+the+object+properties+
++++++++serializer.Populate(jObject.CreateReader(),+target);

++++++++return+target;
++++}

++++public+override+void+WriteJson(JsonWriter+writer,+object+value,+
++++++JsonSerializer+serializer)
++++{
++++++++throw+new+NotImplementedException();
++++}
}+|code-block|syntax|javascript|3068167|现在，您可以使用JsonConverterAttribute注释您的类型，将Json.Net指向自定义转换器：|3068168|[JsonConverter(typeof(MyCustomConverter))]
public+abstract+class+BaseClass{
++private+class+MyCustomConverter+:+JsonCreationConverter<BaseClass>
++{
+++++protected+override+BaseClass+Create(Type+objectType,+
+++++++Newtonsoft.Json.Linq.JObject+jObject)
+++++{
+++++++//TODO:+read+the+raw+JSON+object+through+jObject+to+identify+the+type
+++++++//e.g.+here+I'm+reading+a+'typename'+property:

+++++++if("DerivedType".Equals(jObject.Value<string>("typename")))
+++++++{
+++++++++return+new+DerivedClass();
+++++++}
+++++++return+new+DefaultClass();

+++++++//now+the+base+class'+code+will+populate+the+returned+object.
+++++}
++}
}

public+class+DerivedClass+:+BaseClass+{
++public+string+DerivedProperty+{+get;+set;+}
}

public+class+DefaultClass+:+BaseClass+{
++public+string+DefaultProperty+{+get;+set;+}
}|3068169|现在，您可以将基类型用作参数：|3068170|public+Result+Post(BaseClass+arg)+{

}|3068171|如果我们要发布：|3068172|{+typename:+'DerivedType',+DerivedProperty:+'hello'+}|3068173|那么arg将是DerivedClass的一个实例，但是如果我们发布：|3068174|{+DefaultProperty:+'world'+}|3068175|然后，您将获得DefaultClass的一个实例。|3068176|编辑-为什么我更喜欢这种方法而不是TypeNameHandling.Auto/All|3068177|我确实认为，使用JotaBe所支持的TypeNameHandling.Auto/All并不总是理想的解决方案。在这种情况下很可能是这样--但就我个人而言，我不会这么做，除非：|3068178|3068179|我的API仅供我或我的team|unordered-list-item|3068180|使用我不关心是否有一个双XML兼容的端点|3068181|3068182|当使用Json.Net+TypeNameHandling.Auto或All时，您的web服务器将开始以MyNamespace.MyType,+MyAssemblyName格式发送类型名称。|3068183|我在评论中说过，我认为这是一个安全问题。我从微软读到的一些文档中提到了这一点。这似乎不再被提及，但我仍然觉得这是一个合理的担忧。我不想想要向外界公开命名空间限定的类型名称和程序集名称。它增加了我的攻击面。所以，是的，我的API类型不能有Object属性/参数，但是谁能保证我站点的其余部分是完全没有漏洞的呢？谁能说未来的端点不会暴露利用类型名称的能力呢？为什么仅仅因为它更容易就冒这个险呢？|3068184|此外，如果您正在编写一个“适当的”API，即专门供第三方使用，而不是仅供您自己使用，并且您正在使用Web+API，那么您最有可能希望利用JSON/XML内容类型处理(作为最低要求)。看看您在编写易于使用的文档方面取得了多大进展，这些文档针对XML和JSON格式以不同的方式引用您的所有API类型。|3068185|通过覆盖JSON.Net理解类型名称的方式，您可以将两者结合起来，让调用者完全根据喜好在XML/JSON之间做出选择，而不是因为两者中的类型名称更容易记住。|3068186|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/8030538/how-to-implement-custom-jsonconverter-in-json-net-to-deserialize-a-list-of-base^0|0|8|2M|0|0|0|7|O|0|0|8|M|0|0|0|0|0|0|2|3|7|C|0|0|7|C|0|H|P|0|I|P|0|0|0|0|0|C|L|Y|3|1F|Y|0|3A|6|0|0|0^^$0|@$1|2|3|4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|20|8|@]|9|@$D|21|E|22|1|23]]|A|$]]|$1|F|3|G|5|6|7|24|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|25|8|@$D|26|E|27|J|K]]|9|@]|A|$]]|$1|L|3|M|5|N|7|28|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|29|8|@$D|2A|E|2B|J|K]]|9|@]|A|$]]|$1|S|3|T|5|N|7|2C|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|2D|8|@]|9|@]|A|$]]|$1|W|3|X|5|N|7|2E|8|@]|9|@]|A|$O|P]]|$1|Y|3|Z|5|6|7|2F|8|@]|9|@]|A|$]]|$1|10|3|11|5|N|7|2G|8|@]|9|@]|A|$O|P]]|$1|12|3|13|5|6|7|2H|8|@$D|2I|E|2J|J|K]|$D|2K|E|2L|J|K]]|9|@]|A|$]]|$1|14|3|15|5|N|7|2M|8|@]|9|@]|A|$O|P]]|$1|16|3|17|5|6|7|2N|8|@$D|2O|E|2P|J|K]]|9|@]|A|$]]|$1|18|3|19|5|6|7|2Q|8|@$D|2R|E|2S|J|K]]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2T|8|@$D|2U|E|2V|J|K]]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|2W|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|1F|7|2X|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|1F|7|2Y|8|@]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|30|8|@$D|31|E|32|J|K]|$D|33|E|34|J|K]|$D|35|E|36|J|K]]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|37|8|@$D|38|E|39|J|K]]|9|@]|A|$]]|$1|1N|3|1O|5|6|7|3A|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|6|7|3B|8|@]|9|@]|A|$]]|$1|1R|3|-4|5|6|7|3C|8|@]|9|@]|A|$]]]|1S|$1T|$5|1U|1V|1W|A|$1X|1Y]]]]

You don't need a custom model binder. Nor do you need to muck about with the request pipeline.

Take a look at this other SO: <a href="https://stackoverflow.com/questions/8030538/how-to-implement-custom-jsonconverter-in-json-net-to-deserialize-a-list-of-base">How to implement custom JsonConverter in JSON.NET to deserialize a List of base class objects?</a>.

I used this as the basis for my own solution to the same problem.

Starting off with the <code>JsonCreationConverter&lt;T&gt;</code> referenced in that SO (slightly modified to fix issues with serialization of types in responses):

<pre><code>public abstract class JsonCreationConverter&lt;T&gt; : JsonConverter
{
 /// &lt;summary&gt;
 /// this is very important, otherwise serialization breaks!
 /// &lt;/summary&gt;
 public override bool CanWrite
 {
 get
 {
 return false;
 }
 }
 /// &lt;summary&gt; 
 /// Create an instance of objectType, based properties in the JSON object 
 /// &lt;/summary&gt; 
 /// &lt;param name="objectType"&gt;type of object expected&lt;/param&gt; 
 /// &lt;param name="jObject"&gt;contents of JSON object that will be 
 /// deserialized&lt;/param&gt; 
 /// &lt;returns&gt;&lt;/returns&gt; 
 protected abstract T Create(Type objectType, JObject jObject);

 public override bool CanConvert(Type objectType)
 {
 return typeof(T).IsAssignableFrom(objectType);
 }

 public override object ReadJson(JsonReader reader, Type objectType,
 object existingValue, JsonSerializer serializer)
 {
 if (reader.TokenType == JsonToken.Null)
 return null;
 // Load JObject from stream 
 JObject jObject = JObject.Load(reader);

 // Create target object based on JObject 
 T target = Create(objectType, jObject);

 // Populate the object properties 
 serializer.Populate(jObject.CreateReader(), target);

 return target;
 }

 public override void WriteJson(JsonWriter writer, object value, 
 JsonSerializer serializer)
 {
 throw new NotImplementedException();
 }
} 
</code></pre>

And now you can annotate your type with the <code>JsonConverterAttribute</code>, pointing Json.Net to a custom converter:

<pre><code>[JsonConverter(typeof(MyCustomConverter))]
public abstract class BaseClass{
 private class MyCustomConverter : JsonCreationConverter&lt;BaseClass&gt;
 {
 protected override BaseClass Create(Type objectType, 
 Newtonsoft.Json.Linq.JObject jObject)
 {
 //TODO: read the raw JSON object through jObject to identify the type
 //e.g. here I'm reading a 'typename' property:

 if("DerivedType".Equals(jObject.Value&lt;string&gt;("typename")))
 {
 return new DerivedClass();
 }
 return new DefaultClass();

 //now the base class' code will populate the returned object.
 }
 }
}

public class DerivedClass : BaseClass {
 public string DerivedProperty { get; set; }
}

public class DefaultClass : BaseClass {
 public string DefaultProperty { get; set; }
}
</code></pre>

Now you can use the base type as a parameter:

<pre><code>public Result Post(BaseClass arg) {

}
</code></pre>

And if we were to post:

<pre><code>{ typename: 'DerivedType', DerivedProperty: 'hello' }
</code></pre>

Then <code>arg</code> would be an instance of the <code>DerivedClass</code>, but if we posted:

<pre><code>{ DefaultProperty: 'world' }
</code></pre>

Then you'd get an instance of the <code>DefaultClass</code>.

<h2>EDIT - Why I prefer this method to <code>TypeNameHandling.Auto/All</code></h2>

I do believe that using the <code>TypeNameHandling.Auto/All</code> espoused by JotaBe is not always the ideal solution. It might well be in this case - but personally I won't do it unless:

<ul>
<li>My API is only ever going to be used by me or my team</li>
<li>I don't care about having a dual XML-compatible endpoint</li>
</ul>

When Json.Net <code>TypeNameHandling.Auto</code> or <code>All</code> are used, your web server will start sending out type names in the format <code>MyNamespace.MyType, MyAssemblyName</code>.

I have said in comments that I think this is a security concern. Mention was made of this in some documentation I read from Microsoft. It's not mentioned any more, it seems, however I still feel it's a valid concern. I don't ever want to expose namespace-qualified type names and assembly names to the outside world. It's increasing my attack surface. So, yes, I can not have <code>Object</code> properties/parameters my API types, but who's to say the rest of my site is completely hole-free? Who's to say a future endpoint doesn't expose the ability to exploit type names? Why take that chance just because it's easier?

Also - if you are writing a 'proper' API, i.e. specifically for consumption by third-parties and not just for yourself, and you're using Web API, then you're most likely looking to leverage the JSON/XML content-type handling (as a minimum). See how far you get trying to write documentation that's easy to consume, which refers to all your API types differently for XML and JSON formats.

By overriding how JSON.Net understands the type names, you can bring the two into line, making the choice between XML/JSON for your caller purely based on taste, rather than because the type names are easier to remember in one or the other.

blocks|key|212592|text|你不需要自己去实现它。JSON.NET对它有本机支持。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|212593|您必须为JSON格式化程序指定desired+TypeNameHandling+option，如下所示(在global.asax应用程序启动事件中)：|offset|length|style|CODE|212594|JsonSerializerSettings+serializerSettings+=+GlobalConfiguration.Configuration
+++.Formatters.JsonFormatter.SerializerSettings;
serializerSettings.TypeNameHandling+=+TypeNameHandling.Auto;|code-block|syntax|javascript|212595|如果像上面的示例一样指定Auto，参数将被反序列化为在对象的$type属性中指定的类型。如果缺少$type属性，它将被反序列化为参数的类型。因此，您只需在传递派生类型的参数时指定类型。(这是最灵活的选项)。|212596|例如，如果将此参数传递给Web+API操作：|212597|var+param+=+{
++++$type:+'MyNamespace.MyType,+MyAssemblyName',+//+.NET+fully+qualified+name
++++...+//+object+properties
};|212598|该参数将被反序列化为MyNamespace.MyType类的对象。|212599|这也适用于子属性，也就是说，你可以有一个这样的对象，它指定一个内部属性是一个给定的类型|212600|var+param+=+{+
+++myTypedProperty:+{
++++++$type:+`...`
++++++...
};|212601|在这里您可以看到一个sample+on+JSON.NET+documentation+of+TypeNameHandling.Auto。|212602|This+works+at+least+since+JSON.NET+4+release。|212603|笔记|BOLD|212604|你不需要用attirbutes来装饰任何东西，也不需要做任何其他的定制。它不需要对您的Web+API代码进行任何更改即可工作。|212605|重要说明|212606|The+$type+must+be+the+first+property+of+the+JSON+serialized+object。如果不是，它将被忽略。|212607|与自定义JsonConverter/JsonConverterAttribute的比较|212608|我正在比较本机解决方案to+this+answer。|212609|实现JsonConverter/JsonConverterAttribute|212610|自定义代码您需要实现自定义属性，而自定义JsonConverterAttribute|212611|you需要使用属性来标记parameters|unordered-list-item|212612|
|212613|you需要预先知道parameter|212614|212615|you可能需要实现的类型，或者更改JsonConverter的实现每当您的类型或属性发生更改时|212616|212617|有一种magic+strings的代码味道，以指示期望的属性名称|212618|212619|您没有实现可以与任何类型一起使用的泛型<|212620|212621|>H237JsonConverter+><+code+>H138您正在重新发明轮子|212622|212623|在答案的作者中，有一条关于安全性的评论。除非您做了一些错误的事情(如接受参数的过于泛型的类型，如Object)，否则不会有获得错误类型的实例的风险:+JSON.NET本机解决方案只实例化参数类型的对象或从该对象派生的类型(如果不是这样，您将获得null)。|212624|以下是JSON.NET本机解决方案的优势：|212625|212626|你不需要实现任何东西(你只需要在你的应用程序中配置一次TypeNameHandling+)|212627|你不需要在你的动作parameters|212628|you中使用属性不需要事先知道可能的参数类型:你只需要知道基本类型，并在参数中指定它(它可以是抽象类型，以使多态性更明显)|212629|该解决方案适用于大多数情况(1)无需更改操作解决方案经过广泛测试，和optimized|212630|you不需要魔术字符串|212631|实现是泛型的，可以接受任何派生类型|212632|212633|(1)：如果您希望接收不是从同一基类型继承的参数值，这将不起作用，但我认为这样做没有意义|212634|所以我找不到任何缺点，却发现JSON.NET解决方案有很多优点。|212635|使用自定义JsonConverter/JsonConverterAttribute的原因|212636|这是一个很好的工作解决方案，允许自定义，可以修改或扩展以适应您的特定情况。|212637|如果您想做一些本机解决方案不能做的事情，比如自定义类型名称，或者根据可用的属性名称推断参数的类型，那么一定要根据您自己的情况使用此解决方案。另一个不能定制，不能满足你的需求。|212638|entityMap|0|LINK|mutability|MUTABLE|url|http://james.newtonking.com/json/help/index.html?topic=html/T_Newtonsoft_Json_TypeNameHandling.htm|1|http://james.newtonking.com/json/help/index.html?topic=html/SerializeTypeNameHandling.htm|2|http://james.newtonking.com/archive/2011/11/19/json-net-4-0-release-4-bug-fixes|3|https://stackoverflow.com/questions/20408771/json-net-abstract-derived-class-deserialization-with-webapi-220478603|4|https://stackoverflow.com/questions/12638741/deserialising-json-to-derived-types-in-asp-net-web-api/#12641541|5|http://en.wikipedia.org/wiki/Magic_string_%2528programming%2529#Magic_strings_in_code^0|0|1H|B|F|V|0|0|0|C|4|U|5|1C|5|0|0|0|A|I|0|0|0|A|1L|1|0|0|18|2|0|0|2|0|0|0|4|0|0|1U|3|0|15|2|0|0|Q|B|E|4|0|0|12|2|D|G|M|0|0|16|K|M|0|0|M|0|0|0|I|0|0|0|1B|H|D|0|0|0|W|3|D|5|0|0|0|K|0|0|0|15|0|0|0|3K|1C|6|3E|4|0|0|L|0|0|0|19|R|G|0|0|J|0|0|1P|0|0|17|0|0|B|0|0|H|0|0|0|18|0|0|W|0|0|15|16|2|0|0|11|0|0|2F|0^^$0|@$1|2|3|4|5|6|7|3D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|3E|8|@$D|3F|E|3G|F|G]]|9|@$D|3H|E|3I|1|3J]]|A|$]]|$1|H|3|I|5|J|7|3K|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|3L|8|@$D|3M|E|3N|F|G]|$D|3O|E|3P|F|G]|$D|3Q|E|3R|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|3S|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|3T|8|@]|9|@]|A|$K|L]]|$1|S|3|T|5|6|7|3U|8|@$D|3V|E|3W|F|G]]|9|@]|A|$]]|$1|U|3|V|5|6|7|3X|8|@]|9|@]|A|$]]|$1|W|3|X|5|J|7|3Y|8|@]|9|@]|A|$K|L]]|$1|Y|3|Z|5|6|7|3Z|8|@]|9|@$D|40|E|41|1|42]]|A|$]]|$1|10|3|11|5|6|7|43|8|@]|9|@$D|44|E|45|1|46]]|A|$]]|$1|12|3|13|5|6|7|47|8|@$D|48|E|49|F|14]]|9|@]|A|$]]|$1|15|3|16|5|6|7|4A|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|4B|8|@$D|4C|E|4D|F|14]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|4E|8|@]|9|@$D|4F|E|4G|1|4H]]|A|$]]|$1|1B|3|1C|5|6|7|4I|8|@$D|4J|E|4K|F|14]]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|4L|8|@$D|4M|E|4N|F|14]]|9|@$D|4O|E|4P|1|4Q]]|A|$]]|$1|1F|3|1G|5|6|7|4R|8|@$D|4S|E|4T|F|14]|$D|4U|E|4V|F|G]|$D|4W|E|4X|F|G]]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|4Y|8|@$D|4Z|E|50|F|14]|$D|51|E|52|F|G]]|9|@]|A|$]]|$1|1J|3|1K|5|1L|7|53|8|@$D|54|E|55|F|14]]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|56|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|1L|7|57|8|@$D|58|E|59|F|14]]|9|@]|A|$]]|$1|1Q|3|1N|5|6|7|5A|8|@]|9|@]|A|$]]|$1|1R|3|1S|5|1L|7|5B|8|@$D|5C|E|5D|F|14]|$D|5E|E|5F|F|G]]|9|@]|A|$]]|$1|1T|3|1N|5|6|7|5G|8|@]|9|@]|A|$]]|$1|1U|3|1V|5|1L|7|5H|8|@$D|5I|E|5J|F|14]]|9|@$D|5K|E|5L|1|5M]]|A|$]]|$1|1W|3|1N|5|6|7|5N|8|@]|9|@]|A|$]]|$1|1X|3|1Y|5|1L|7|5O|8|@$D|5P|E|5Q|F|14]]|9|@]|A|$]]|$1|1Z|3|1N|5|6|7|5R|8|@]|9|@]|A|$]]|$1|20|3|21|5|1L|7|5S|8|@$D|5T|E|5U|F|14]]|9|@]|A|$]]|$1|22|3|-4|5|6|7|5V|8|@]|9|@]|A|$]]|$1|23|3|24|5|6|7|5W|8|@$D|5X|E|5Y|F|14]|$D|5Z|E|60|F|G]|$D|61|E|62|F|G]]|9|@]|A|$]]|$1|25|3|26|5|6|7|63|8|@$D|64|E|65|F|14]]|9|@]|A|$]]|$1|27|3|-4|5|6|7|66|8|@]|9|@]|A|$]]|$1|28|3|29|5|1L|7|67|8|@$D|68|E|69|F|14]|$D|6A|E|6B|F|G]]|9|@]|A|$]]|$1|2A|3|2B|5|1L|7|6C|8|@$D|6D|E|6E|F|14]]|9|@]|A|$]]|$1|2C|3|2D|5|1L|7|6F|8|@$D|6G|E|6H|F|14]]|9|@]|A|$]]|$1|2E|3|2F|5|1L|7|6I|8|@$D|6J|E|6K|F|14]]|9|@]|A|$]]|$1|2G|3|2H|5|1L|7|6L|8|@$D|6M|E|6N|F|14]]|9|@]|A|$]]|$1|2I|3|2J|5|1L|7|6O|8|@$D|6P|E|6Q|F|14]]|9|@]|A|$]]|$1|2K|3|-4|5|6|7|6R|8|@]|9|@]|A|$]]|$1|2L|3|2M|5|6|7|6S|8|@$D|6T|E|6U|F|14]]|9|@]|A|$]]|$1|2N|3|2O|5|6|7|6V|8|@$D|6W|E|6X|F|14]]|9|@]|A|$]]|$1|2P|3|2Q|5|6|7|6Y|8|@$D|6Z|E|70|F|14]|$D|71|E|72|F|14]]|9|@]|A|$]]|$1|2R|3|2S|5|6|7|73|8|@$D|74|E|75|F|14]]|9|@]|A|$]]|$1|2T|3|2U|5|6|7|76|8|@$D|77|E|78|F|14]]|9|@]|A|$]]|$1|2V|3|-4|5|6|7|79|8|@]|9|@]|A|$]]]|2W|$2X|$5|2Y|2Z|30|A|$31|32]]|33|$5|2Y|2Z|30|A|$31|34]]|35|$5|2Y|2Z|30|A|$31|36]]|37|$5|2Y|2Z|30|A|$31|38]]|39|$5|2Y|2Z|30|A|$31|3A]]|3B|$5|2Y|2Z|30|A|$31|3C]]]]

You don't need to implement it by yourself. JSON.NET has native support for it.

You have to specify the <a href="http://james.newtonking.com/json/help/index.html?topic=html/T_Newtonsoft_Json_TypeNameHandling.htm" rel="noreferrer">desired TypeNameHandling option</a> for the JSON formatter, like this (in <code>global.asax</code> application start event):

<pre><code>JsonSerializerSettings serializerSettings = GlobalConfiguration.Configuration
 .Formatters.JsonFormatter.SerializerSettings;
serializerSettings.TypeNameHandling = TypeNameHandling.Auto;
</code></pre>

If you specify <code>Auto</code>, like in the above sample, the parameter will be deserialized to the type specified in the <code>$type</code> property of the object. If the <code>$type</code> property is missing, it will be deserialized to the parameter's type. So you only have to specify the type when you're passing a parameter of a derived type. (This is the most flexible option).

For example, if you pass this parameter to a Web API action:

<pre><code>var param = {
 $type: 'MyNamespace.MyType, MyAssemblyName', // .NET fully qualified name
 ... // object properties
};
</code></pre>

The parameter will be deserialized to an object of <code>MyNamespace.MyType</code> class.

This also works fro sub-properties, i.e., you can have an object like this, which specifies that an inner property is of a given type

<pre><code>var param = { 
 myTypedProperty: {
 $type: `...`
 ...
};
</code></pre>

Here you can see a <a href="http://james.newtonking.com/json/help/index.html?topic=html/SerializeTypeNameHandling.htm" rel="noreferrer">sample on JSON.NET documentation of TypeNameHandling.Auto</a>.

<a href="http://james.newtonking.com/archive/2011/11/19/json-net-4-0-release-4-bug-fixes" rel="noreferrer">This works at least since JSON.NET 4 release</a>.

NOTE

You don't need to decorate anything with attirbutes, or do any other customization. It will work without any changes in your Web API code.

IMPORTANT NOTE

<a href="https://stackoverflow.com/questions/20408771/json-net-abstract-derived-class-deserialization-with-webapi-220478603">The $type must be the first property of the JSON serialized object</a>. If not, it will be ignored.

COMPARISON TO CUSTOM JsonConverter/JsonConverterAttribute

I'm comparing the native solution <a href="https://stackoverflow.com/questions/12638741/deserialising-json-to-derived-types-in-asp-net-web-api/#12641541">to this answer</a>.

To implement the <code>JsonConverter</code>/<code>JsonConverterAttribute</code>:

<ul>
<li>you need to implement a custom <code>JsonConverter</code>, and a custom <code>JsonConverterAttribute</code></li>
<li>you need to use attributes to mark the parameters</li>
<li>you need to know beforehand the possible types expected for the parameter</li>
<li>you need to implement, or change the implementation of your <code>JsonConverter</code> whenever your types or properties change</li>
<li>there is a code smell of <a href="http://en.wikipedia.org/wiki/Magic_string_%28programming%29#Magic_strings_in_code" rel="noreferrer">magic strings</a>, to indicate the expected property names</li>
<li>you are not implementing something generic that can be used with any type</li>
<li>you're reinventing the wheel</li>
</ul>

In the author of the answer there's a comment regarding security. Unless you do something wrong (like accepting a too generic type for your parameter, like <code>Object</code>) there is no risk of getting an instance of the wrong type: JSON.NET native solution only instantiates an object of the parameter's type, or a type derived from it (if not, you get <code>null</code>).

And these are the advantages of JSON.NET native solution:

<ul>
<li>you don't need to implement anything (you only have to configure the <code>TypeNameHandling</code> once in your app)</li>
<li>you don't need to use attributes in your action parameters</li>
<li>you don't need to know the possible parameter types beforehand: you simply need to know the base type, and specify it in the parameter (it could be an abstract type, to make polymorphism more obvious)</li>
<li>the solution works for most cases (1) without changing anything</li>
<li>this solution is widely tested, and optimized</li>
<li>you don't need magic strings</li>
<li>the implementation is generic, and will accept any derived type</li>
</ul>

(1): if you want to receive parameter values that don't inherit from the same base type, this will not work, but I see no point on doing so

So I can't find any disadvantages, and find many advantages on JSON.NET solution.

WHY USING CUSTOM JsonConverter/JsonConverterAttribute

This is a good working solution that allows customization, that can be modified or extended to adapt it to your particular case.

If you want to do something that the native solution cannot do, like customizing the type names, or inferring the type of the parameter based on available property names, then do use this solution adapted to your own case. The other one cannot be customized, and will not work for your needs.

blocks|key|2854744|text|如果您想使用TypeNameHandling.Auto，但又关心安全性，或者不喜欢需要这种级别的幕后知识的用户，您可以自行处理$type的反序列化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2854745|public+class+InheritanceSerializationBinder+:+DefaultSerializationBinder
{
++++public+override+Type+BindToType(string+assemblyName,+string+typeName)
++++{
++++++++switch+(typeName)
++++++++{
++++++++++++case+"parent[]":+return+typeof(Class1[]);
++++++++++++case+"parent":+return+typeof(Class1);
++++++++++++case+"child[]":+return+typeof(Class2[]);
++++++++++++case+"child":+return+typeof(Class2);
++++++++++++default:+return+base.BindToType(assemblyName,+typeName);
++++++++}
++++}
}|code-block|syntax|javascript|2854746|然后将其挂接到global.asax.Application__Start中|2854747|var+config+=+GlobalConfiguration.Configuration;
++++++++config.Formatters.JsonFormatter.SerializerSettings+=+new+JsonSerializerSettings+{+Binder+=+new+InheritanceSerializationBinder()+};|2854748|最后，我在包含不同类型对象的属性上使用了包装类和JsonProperty(TypeNameHandling+=+TypeNameHandling.Auto)，因为我无法通过配置实际的类来使其工作。|2854749|这种方法允许用户在请求中包含所需的信息，同时允许允许值的文档独立于平台、易于更改和易于理解。所有这些都不需要编写您自己的转换器。|2854750|致谢：https://mallibone.com/post/serialize-object-inheritance-with-json.net向我展示了该字段属性的自定义反序列化程序。|offset|length|2854751|entityMap|0|LINK|mutability|MUTABLE|url|https://mallibone.com/post/serialize-object-inheritance-with-json.net^0|0|0|0|0|0|0|3|1X|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|16|8|@]|9|@$Q|17|R|18|1|19]]|A|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

If you want to use the TypeNameHandling.Auto but are concerned with security or dont like api consumers needing that level of behind the scenes knowledge you can handle the $type deserialize your self. 

<pre><code>public class InheritanceSerializationBinder : DefaultSerializationBinder
{
 public override Type BindToType(string assemblyName, string typeName)
 {
 switch (typeName)
 {
 case "parent[]": return typeof(Class1[]);
 case "parent": return typeof(Class1);
 case "child[]": return typeof(Class2[]);
 case "child": return typeof(Class2);
 default: return base.BindToType(assemblyName, typeName);
 }
 }
}
</code></pre>

Then hook this up in global.asax.Application__Start

<pre><code>var config = GlobalConfiguration.Configuration;
 config.Formatters.JsonFormatter.SerializerSettings = new JsonSerializerSettings { Binder = new InheritanceSerializationBinder() };
</code></pre>

finally i have used a wrapper class and [JsonProperty(TypeNameHandling = TypeNameHandling.Auto)] on a properpty containing the object with different types as i have not been able to get it to work by configuring the actual class.

This approach allows consumers to include the needed information in their request while allowing the documentation of the allowable values to be platform independent, easy to change, and easy to understand. All without having to write your own converster. 

Credit to : <a href="https://mallibone.com/post/serialize-object-inheritance-with-json.net" rel="nofollow noreferrer">https://mallibone.com/post/serialize-object-inheritance-with-json.net</a> 
for showing me the custom deserializer of that field property.

I'm calling a method of my WebAPI sending a JSON that I would like to match (or bind) with a model.
In the controller I have a method like:
<pre><code>public Result Post([ModelBinder(typeof(CustomModelBinder))]MyClass model);
</code></pre>
'MyClass', which is given as a parameter is an abstract class. I would like that at, depending of the type of json passed, the correct inherited class is instantiated.
To achieve it, I'm trying to implement a custom binder. The problem is that (I don't know if it's very basic but I can't find anything) I don't know how to retrieve the raw JSON (or better, some kind of serialization) that comes in the request.
I see:
<ul>
<li>actionContext.Request.Content</li>
</ul>
But all methods are exposed as async. I don't know who this fits with passing the generate model to the controller method...

Deserialising JSON to derived types in Asp.Net Web API

我正在调用我的WebAPI的一个方法，发送一个我想要与模型匹配(或绑定)的JSON。在控制器中，我有一个类似如下的方法：public Result Post([ModelBinder(typeof(CustomModelBinder))]MyClass model);‘'MyClass’是一个抽象类，它是作为参数给出的...

问在Asp.Net Web API中将JSON反序列化为派生类型
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Asp.Net Web API中将JSON反序列化为派生类型EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Asp.Net Web API中将JSON反序列化为派生类型
EN