Jiwa

Your other option would be to annotate your DTO classes for both like the following in an example for ServiceStack

Code: Select all

[DataContract]
public class Customer
{
    [DataMember(Name="first_name")]
    public string FirstName { get; set; }

    [DataMember(Name="last_name")]
    public string LastName { get; set; }
}


okay. By the way even if I not use Newtonsoft but due to newtonsoft attribute in models I need to put the reference of it so why its saying Newtonsoft could not be load. Do I need to remove all attributes from models ?

SBarnes wrote:Your other option would be to annotate your DTO classes

That'll get the snake case problem solved - but the two solutions I provided also did that - so I can only assume the OP has other reasons besides just the snake case.

iamgurney wrote:okay. By the way even if I not use Newtonsoft but due to newtonsoft attribute in models I need to put the reference of it so why its saying Newtonsoft could not be load. Do I need to remove all attributes from models ?

There is not enough information for us to help you.

Provide a plugin which has the issue and I can advise you then.

As well as provide the plugin also explain where you got the embedded reference for Newtonsoft from and remember Jiwa only installs .net 4.7.1.

The attached plugin will use the Newtonsoft Json serialiser for serialising a specific class - my example is the StartupLogEntry type which is what you see when you visit /Queries/StartupLog.

The essential part is:

Code: Select all

ServiceStack.Text.JsConfig<JiwaFinancials.Jiwa.JiwaServiceModel.Startup.Diagnostics.StartupLogEntry>.SerializeFn = input =>
{               
   return Newtonsoft.Json.JsonConvert.SerializeObject(input);
};

Perhaps you can find a way to make it work for all types, but if not you'll need to add each type - copy and paste the registration of the SerializeFn to use and change the type "JiwaFinancials.Jiwa.JiwaServiceModel.Startup.Diagnostics.StartupLogEntry" to be the type you want to use.

The following link may also be of help https://forums.servicestack.net/t/how-t ... stack/5152 where you can override the toJson method on the DTO, you could always use inheritance and create the method in one spot namely the parent class.

SBarnes wrote:The following link may also be of help https://forums.servicestack.net/t/how-t ... stack/5152 where you can override the toJson method on the DTO, you could always use inheritance and create the method in one spot namely the parent class.

That's fine if the OP only needs their own DTO's to be serialised and deserialised using Newtonsoft's JSon.NET - but what if they need say our sales order route to emit it using that? The only way to do that is create a DTO which inherits from our sales order DTO, implements the ToJSon method and create a custom service and route which uses the custom DTO.

It's not ideal, but possible - but it's creating a lot of future technical debt someone has to maintain.

I'm still not convinced that Newtonsoft's JSon.NET HAS to be used. Without knowing the actual details of the requirements we can only assume it is necessary... but as I said it's creating a lot of potential future problems the OP is likely not considering.

Of course the other option is to go around the problem completely you can actually tell web api what serializer to use so you could always do the reverse and have web api use ServiceStack

SBarnes wrote:The following link may also be of help https://forums.servicestack.net/t/how-t ... stack/5152 where you can override the toJson method on the DTO, you could always use inheritance and create the method in one spot namely the parent class.

Actually in that topic, the OP of that topic also points out they arrived at a solution using a custom request DTO binder.

http://docs.servicestack.net/serializat ... dto-binder

This gives you access to the IHttpRequest object letting you parse it manually so you can construct and return the strong-typed Request DTO manually which will be passed to the service instead.

That sounds ideal, in that existing services and DTO's don't need to change, but the custom binder is what deserialises the Json into a DTO, and from there it's passed on to the registered service.