C# DataContracts – Using Subclasses for DataContracts with JSON

cjson

I have a RESTful call that can modify the state of an instance. My problem is that the JSON is different based on the type of action the user is taking, it could be a SetProperty action or a SetState action (among others).

For example, a POST /api/sample/ _would send the following JSON

{ 
  instanceId: 12312,      
  actionId: 12345, // Maps to a SetState action
  desiredState: 'CURATION'
}

But when calling the same URL for a SetProperty, the JSON would look like

{ 
  instanceId: 12312,      
  actionId: 25354, // Maps to a SetProperty action
  propName: "PropA",
  propValue: "user-input" 
}

I use the following data contract

[DataContract]
class PostInstanceRequest {
    [DataMember]
    int instanceId;
    [DataMember]
    int actionId;
    [DataMember]
    string desiredState;  // Only used for SetState
    [DataMember]
    string propName;   // Only used for SetProperty
    [DataMember]
    string propValue;  // Only used for SetProperty
    // Many more action specific properties here...
}

I don't really like this because it feels like I should have a base class for the common properties, and then I should define more base classes with the specific properties.

SetStatePostInstanceRequest, that adds desiredState
SetPropertyPostInstanceRequest, that adds propName and propValue

However, if I do that, I don't know what class to deserialize it into. I would have to first deserialize as a PostInstanceRequest, check the actionId property, and then deserialize it to the correct subclass.

A possible compromise is to use composition

[DataContract]
class SetStateAction {
    [DataMember]
    string desiredState;
}

[DataContract]
class SetPropAction {
    [DataMember]
    string propName;
    [DataMember]
    string propValue;
}

[DataContract]
class PostInstanceRequest {
    [DataMember]
    int instanceId;
    [DataMember]
    int actionId;
    [DataMember]
    SetPropAction setPropParams;
    [DataMember]
    SetStateAction setActionParams;
    // More references to action specific classes down here
}

Which of the options is going to cause me less trouble? Or is there an even better way that I didn't think of?

Best Answer

Did you author the service which you are posting to? If so, I would recommend changing it, so that you post SetState data to something like /api/sample/State, and post SetProperty data to /api/sample/Property. Then you would have separate controller actions for each service method, with each receiving only the desired parameters. If the service isn't yours and you can't modify it however, then obviously you're a bit stuffed. Otherwise, read this: http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection

Update

If you definitely want to retain a single action, at the same address, there is something you can do. You can define your controller action to take an interface / base class-typed parameter, and have the json deserializer use type information which you provide in your json to determine which class to rehydrate with your data, for example:

public abstract class ThingBase
{
    public int instanceId { get ; set; }
    public int actionId { get; set; }
}

public class SetStateThing : ThingBase
{
    public string desiredState { get; set; }
}

public class SetPropertyThing : ThingBase
{
    public string propName { get; set; }
    public string propValue { get; set; }
}

public class MyController
{
    public HttpResponseMessage Post([FromBody]ThingBase thing)
    {
        //use thing
    }
}

Your json would become, for example:

{
$type: "MyAssembly.SetStateThing, MyAssembly",
instanceId: 12312,      
actionId: 12345, // Maps to a SetState action
desiredState: "CURATION"
}

{
$type: "MyAssembly.SetPropertyThing, MyAssembly",
instanceId: 12312,      
actionId: 25354, // Maps to a SetProperty action
propName: "PropA",
propValue: "user-input" 
}

The trick is to set up the serializer settings correctly (in your WebApiConfig.cs Register(HttpConfiguration config) method for example):

config.Formatters.JsonFormatter.SerializerSettings.TypeNameHandling = TypeNameHandling.Objects;

I used this with an interface, but an abstract base class seems a better fit for your scenario.

Related Solutions

How to get around the Circular Reference issue with JSON and Entity

I see two distinct subjects in your question:

How to manage circular references when serializing to JSON?
How safe is it to use EF entities as model entities in you views?

Concerning circular references I'm sorry to say that there is no simple solution. First because JSON cannot be used to represent circular references, the following code:

var aParent = {Children : []}, aChild  = {Parent : aParent};
aParent.Children.push(aChild);
JSON.stringify(aParent);

Results in: TypeError: Converting circular structure to JSON

The only choice you have is to keep only the composite --> component part of the composition and discard the "back navigation" component --> composite, thus in you example:

class parent
{
    public List<child> Children{get;set;}
    public int Id{get;set;}
}
class child
{
    public int ParentId{get;set;}
    [ForeignKey("ParentId"), ScriptIgnore]
    public parent MyParent{get;set;}
    public string name{get;set;}
}

Nothing prevents you from recomposing this navigation property on your client side, here using jQuery:

$.each(parent.Children, function(i, child) {
  child.Parent = parent;  
})

But then you will need to discard it again before sending it back to the server, for JSON.stringify won't be able to serialize the circular reference:

$.each(parent.Children, function(i, child) {
  delete child.Parent;  
})

Now there is the issue of using EF entities as your view model entities.

First EF is likely to using Dynamic Proxies of your class to implement behaviors such as change detection or lazy loading, you have to disable those if you want to serialize the EF entities.

Moreover using EF entities in the UI can be at risk since all the default binder will mapping every field from the request to entities fields including those you did not want the user to set.

Thus, if you want you MVC app to be properly designed I would recommended to use a dedicated view model to prevent the "guts" of your internal business model from being exposed to the client, thus I would recommend you a specific view model.

C# – suggest structure for classes that maps to json with dynamic data without using dynamic or object reference

If I'm understanding you correctly, you're trying to find a statically-typed way to say "a value of type Section can be either a value of type Highlights, Chart, or Tweets". There are many terms for this, including tagged union, discriminated union, variant, or sum type but they all refer to the same concept. Sum types are a standard feature in statically-typed functional programming languages, but with a bit of ingenuity you can roll your own in C#. Using that answer as a template, and adding sealed to make sure no one adds any extra subclasses, your Section type would look something like this:

public abstract class Section
{
    // Prevent subclassing outside of this scope
    private Section() {}

    // Subclass implementation calls the appropriate function.
    public abstract R Match<R>(Func<H, R> IfHighlight, Func<C, R> IfChart, Func<T, R> IfTweet);

    // Convenience wrapper for when the caller doesn't want to return a value
    // from the match expression.
    public sealed void Match(Action<H> IfHighlight, Action<C> IfChart, Action<T> IfTweet)
    {
        this.Match<int>(
            IfHighlight: Section => { IfHighlight(Section); return 0; },
            IfChart: Section => { IfChart(Section); return 0; },
            IfTweet: Section => { IfTweet(Section); return 0; }
        );
    }

    // From here on down, you define your specific types as usual, and override Match to call
    // the correct function

    public sealed class Highlight : Section
    {
        // Implementation goes here

        public override R Match<R>(Func<H, R> IfHighlight, Func<C, R> IfChart, Func<T, R> IfTweet)
        {
            return IfHighlight(this);
        }
    }

    public class Chart : Section
    {
        // Implementation goes here

        public override R Match<R>(Func<H, R> IfHighlight, Func<C, R> IfChart, Func<T, R> IfTweet)
        {
            return IfChart(this);
        }
    }

    public class Tweet : Section
    {
        // Implementation goes here

        public override R Match<R>(Func<H, R> IfHighlight, Func<C, R> IfChart, Func<T, R> IfTweet)
        {
            return IfTweet(this);
        }
    }
}

With that in place, you can declare variables of type Section, and act on them by passing 3 functions to the Match methods:

Section section = deserializeJson()
section.Match(
    IfHighlight: highlight => /* code to use if you get a Highlight */
    IfChart: chart => /* ... */
    IfTweet: tweet => /* ... */
);

You could just as easily have a collection of Sections and operate on them that way when you iterate over it.

Best Answer

Related Solutions

How to get around the Circular Reference issue with JSON and Entity

C# – suggest structure for classes that maps to json with dynamic data without using dynamic or object reference

Related Topic