opened
ssa3512
username_0
I was playing around with middleware and storage queue triggered functions (this will be so nice to have) but the way the data was stored in the function execution context did not line up with my expectations when the function is taking a strongly typed object coming in as JSON.

Given the class:
```cs
public class MessageInfo
{
    public int Id { get; set; }
    public string Name { get; set; }
}
```
and the queue message `{"Name":"Steve","Id":2}`

I get the following binding data
![image](https://user-images.githubusercontent.com/1991399/112567840-e080c880-8db7-11eb-834d-66c18a04e746.png)

It seems odd that the individual property values are in the binding data dictionary as opposed to the deserialized MessageInfo object.

Can you provide some clarification on this? It feels even weirder if I use a nested data structure like this:
```cs
public class MessageInfo
{
    public int Id { get; set; }
    public Person Person { get; set; }
}

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}`
```
The "Id" field is in the data dictionary as the raw value, and the "Person" value is there as JSON. The entire serialized value is there as QueueTrigger.

![image](https://user-images.githubusercontent.com/1991399/112568396-c7c4e280-8db8-11eb-9903-eda6f0bbeda9.png)

Is there any way to access the fully deserialized object from middleware, or will I need to manually deserialize to access the data in a strongly typed manner? What would happen if the incoming object used in my binding had a top level property that conflicted with one of the defaults on the binding type (`DateTime ExpirationTime` for example) - which value would show in the dictionary?
BindingData values are confusing and don't line up with input object structure
issue
created
fabiocav
username_1
The data exposed in biding data is the raw information we receive from the actual extension running in WebJobs. This is pre-processing/binding in the worker (those are the values ultimately used by the converters to perform model binding).

When binding to POCOs/Complex types, most extensions (queues included) will default to JSON serialization. This is ultimately controlled by the extension itself, and you'll see changes depending on how things are configured (including enhancements in the future, like the ability to pass an object reference only). 

Based on what you're describing, it sounds like you'd better served by working directly against the model binding feature (which is still undergoing reviews, so not part of the public API), which performs all the conversions and will expose the APIs you'd need to get the binding payload as a specific type. 

For the binding rules (for default values, for example), it's hard to answer that generically since ultimately, the extension author is in control (i.e. the storage extension defines how that information is passed to, and received from, the worker)

Right now, with the current state of what is currently exposed, handling the deserialization manually would be the most straight forward way, but this is an example of an area that will be seeing a lot of enhancements to make scenarios like what you're describing simpler.
comment
created
ssa3512
username_0
Thanks - it sounds like this is exactly what I am looking for. Do you have an separate public issue/discussion about this API I can follow?
comment