My test class:
public class TestA
{
public IEnumerable<string> Collection { get; set; }
}
When I call extension method .ToJsv() from ServiceStack.Text on TestA object with property Collection which is an array with some null values, the result does not contain null values. Even setting JsConfig.IncludeNullValues = true; does not bring the solution.
Test code:
var obj = new TestA { Collection = new[] { "T", null } };
var result = obj.ToJsv(); //here I get {Collection:[T,]} instead of {Collection:[T,null]}
Thanks for any suggestions.
Given its format JSV can’t serialize null values as they’d be indistinguishable from the ‘null’ literal string so it’s lack of a value is what indicates a property is null, but that’s no something that’s you’ll be able to rely on if you want to send null items in a collection in which case you’d need to special casing like maintaining which items are null in a different property or you’d need to use a different serializer.
I'm trying to get some help on deserializing a JSON reponse to a DataSet.
in theory this should be easy as using this example
http://www.newtonsoft.com/json/help/html/DeserializeDataSet.htm
DataSet dataSet = JsonConvert.DeserializeObject<DataSet>(json);
DataTable dataTable = dataSet.Tables["Table1"];
However the JSON I am getting back is supplemented / decorated using "odata.metadata"
see below.
{"odata.metadata":"http://nodts004.cloudapp.net:7058/TNPMaster2016Dev/OData/$metadata#NP_Customer","value":[{"No":"01121212","Name":"Spotsmeyer's Furnishings","City":"Miami","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"0","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"0","Payments_LCY":"0","Inv_Amounts_LCY":"0","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":6,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"},{"No":"01445544","Name":"Progressive Home Furnishings","City":"Chicago","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"1499.02","Sales_LCY":"1499.02","Profit_LCY":"305.12","Balance_Due_LCY":"1499.02","Payments_LCY":"0","Inv_Amounts_LCY":"1499.02","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":0,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":1,"No_of_Pstd_Invoices":1,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"},{"No":"01454545","Name":"New Concepts Furniture","City":"Atlanta","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"222241.32","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"222241.32","Payments_LCY":"0","Inv_Amounts_LCY":"222241.32","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"15609","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":1,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"8702.82","Shipped_Not_Invoiced_LCY":"0"},{"No":"01905893","Name":"Candoxy Canada Inc.","City":"Thunder Bay","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"0","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"0","Payments_LCY":"0","Inv_Amounts_LCY":"0","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":0,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"},{"No":"01905899","Name":"Elkhorn Airport","City":"Elkhorn","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"0","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"0","Payments_LCY":"0","Inv_Amounts_LCY":"0","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":0,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"}]}
I have for certain scenarios created a POCO to deal with the returned json for the properties
public class RootObject2
{
[JsonProperty("odata.metadata")]
public string odatametadata { get; set; }
[JsonProperty("odata.nextLink")]
public string NextLinkUrl { get; set; }
}
and
public class RootObject
{
[JsonProperty("odata.metadata")]
public string odatametadata { get; set; }
[JsonProperty("odata.nextLink")]
public string NextLinkUrl { get; set; }
public List<UrlItem> Value { get; set; }
}
These are used in instances where I know the returned JSON will contain certain structures and can be safely dealt with.
The problem is that the VALUE part of the JSON will be dynamic in many instances and I wanted to take advantage of the dynamic nature of the JSONConvert functions to build DataSets that I can then pass through as a source for an Excel table. It should be noted that the data coming back will never be definable.
When i use the code:
DataSet dataSet = JsonConvert.DeserializeObject<DataSet>(json);
I get an error, because I need to be passing the sting / contents of the VALUE node/element to the DeserialseObject.
Is there a setting on the JSON converter that allows this?
I have tried to create a POCO with a string field and then after mapping the VALUE node to the POCO passing the string to the JSONConverter but this errors out.
A solution to this would be most helpful.
Thanks.
B....
You can create your own custom subclass of DataSetConverter that strips out non-array-valued properties from the root DataSet object:
public class DataSetConverter : Newtonsoft.Json.Converters.DataSetConverter
{
public override bool CanConvert(Type valueType)
{
if (!base.CanConvert(valueType))
return false;
return typeof(DataSet).IsAssignableFrom(valueType);
}
public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
{
if (reader.TokenType == JsonToken.Null)
{
return null;
}
var token = JObject.Load(reader);
// Strip non-array-valued properties
foreach (var property in token.Properties().Where(p => p.Value.Type != JTokenType.Array).ToList())
property.Remove();
using (var subReader = token.CreateReader())
{
while (subReader.TokenType == JsonToken.None)
subReader.Read();
return base.ReadJson(subReader, objectType, existingValue, serializer); // Use base class to convert
}
}
}
Then use it as follows:
var dataSet = JsonConvert.DeserializeObject<DataSet>(json, new JsonSerializerSettings { Converters = new JsonConverter[] { new DataSetConverter() } });
var dataTable = dataSet.Tables["value"];
Prototype fiddle.
I would like to post a JSON object to my service stack service and use a dynamic property in the request DTO. All approaches I have tried so far leave the object being a NULL value.
The javascript code I use:
$.getJSON(
"/api/json/reply/Hello",
{
Name: "Murphy",
Laws: {
SomeProp: "A list of my laws",
SomeArr: [
{ Title: "First law" },
{ Title: "Second law" },
{ Title: "Third law" }
]
}
},
function(data) {
alert(data.result);
}
);
The DTO to receive the request:
public class Hello
{
public string Name { get; set; }
public dynamic Laws { get; set; }
}
I also tried to use an object and JsonObject instead of dynamic in the DTO.
To be complete, here's the service too:
public class HelloService : Service
{
public object Any(Hello request)
{
return new HelloResponse { Result = "Hello, " + request.Name };
}
}
Murphy comes through in the Name property without any problems, but the Laws property remains NULL.
In the end, I want to somehow iterate (using reflection?) over the Laws property and get all the contained properties and values.
I cannot use a typed DTO here, because I don't know the JSON of the Laws property at development time (and it can change quite frequently).
Thanks for any help!
The .NET 3.5 library builds of ServiceStack on NuGet doesn't have native support for the .NET 4.0+ dynamic type. You can pass JSON into a string property and dynamically parse it on the server:
public object Any(Hello request)
{
var laws = JsonObject.Parse(request.Laws);
laws["SomeProp"] //
laws.ArrayObjects("SomeArr") //
}
Otherwise You can use Dictionary<string,string> or if you specify in your AppHost:
JsConfig.ConvertObjectTypesIntoStringDictionary = true;
You can use object which will treat objects like a string dictionary.
Otherwise dynamic shouldn't be on the DTO as it's meaningless as to what the service expects. You could just add it to the QueryString. You can use the JSV Format to specify complex object graphs in the QueryString, e.g:
/hello?laws={SomeProp:A list of my laws,SomeArr:[{Title:First Law}]}
Note: the spaces above gets encoded with %20 on the wire.
Which you can access in your services with:
public object Any(Hello request)
{
var laws = base.QueryString["laws"].FromJsv<SomeTypeMatchingJsvSent>();
}
I have a class that has 2 properties and a constructor:
public class Card
{
public int CardName {get;set;}
public bool IsActive {get;set;}
public Card (int cardName, bool isActive)
{
CardName = cardName;
IsActive = isActive;
}
}
How do I force the developer to use the constructor instead of doing the following:
var card = new Card{ CardName = "blab", IsActive = true };
On a side note, what is the statement above called? Is that a lazy loading statement?
You already have.
By not having an empty constructor you've removed the ability to use the object initializer method of creating an object.
This:
var card = new Card{ CardName = "blab", IsActive = true };
is the same as this
var card = new Card() { CardName = "blab", IsActive = true };
And in this context new Card() is not valid.
That depends on why you want to prevent the syntax in question.
The object initializer syntax is shorthand for setting a bunch of properties immediately after construction. That is, this:
var c = new Card { CardName = "foo", IsActive = true };
Is semantically identical to this:
var c = new Card();
c.CardName = "foo";
c.IsActive = true;
In both cases, a constructor does run, but its immediately followed by a series of property initializers to apply to the new object.
In your case, since there is no parameterless constructor, you cannot use the object initializer syntax the way you posted. However, it is legal to pass constructor parameters along with the object initializer, so the following would be legal for your class:
var c = new Card("", false) { CardName = "foo", IsActive = true };
(One could argue that this syntax makes the meaning of values more clear than simply passing them to a constructor; one could also argue its just being excessively stubborn :) I could go either way)
You could prevent this second syntax from working by removing the public setters for those properties. If your goal is to prevent the user from changing the values passed into the constructor, making an immutable Card object, for example, that would be the way to go.
I should point out, though, that if one of my juniors asked me this question at work I'd really want to know why they found it necessary to prevent object initialization from being used. There are valid reasons, of course, but they are usually not the source of the question. Object initializers are a good thing -- there are cases where this syntax is very convenient (particularly with LINQ) and I use it all the time.
If you do some kind of setup in the constructor based on the initial values, but those properties are public-settable, you already have to deal with a case where the user changes those values after construction. If your goal is merely to ensure that some "setup" code happens when the object is first constructed, put that code into a default constructor and chain them together:
public class Card
{
public string CardName { get; set; }
public bool IsActive { get; set; }
public Card()
{
// setup code here.
}
public Card ( string name, bool active )
: this()
{
this.CardName = name;
this.IsActive = active;
}
}
Declare the getters of the property as 'Private'.
Something like Public int CardName {private get; set;}.
I have a function that returns objects of different types based on the parameter passed to this function.
Is it possible to add these different object types to a collection based on some identifier in C# 4.0?
Usually we do something like this
List or List
but i want one collection which can add object of any type.
Instead of just making a List<object> like other posters are recommending, you may want to define an interface eg IListableObject that contains a few methods that your objects need to implement. This will make any code using these objects much easier to write and will guard against unwanted objects getting into the collection down the line.
Yes, it is called object. Eg:
var objlist = new List<object>();
objlist.Add(1);
objlist.Add(true);
objlist.Add("hello");
You could use object[], List<object>, ArrayList, IEnumerable, ... but if those types have a common base type it would be better to stick to a strongly typed collection.
Really your collection should be as specific as you can make it. When you say
objects of different types
Do these objects have anything in common? Do they implement a common interface?
If so you you can specialise the list on that interface List<IMyInterface>
Otherwise List<object> will do what you want.
Update
No, not really.
I'm sorry but I'm going to question your design.
If you have a collection of different objects, how do you decide how to use one of the objects?
You're going to have a large switch statement switching on the type of the object, then you cast to a specific object and use it.
You also have have a similar switch statement in your factory method that creates the object.
One of the benefits of Object Orientation is that if you design your objects correctly then you don't need to do these large "If it's this object do this.Method(), if it's that object do that.OtherMethod()".
Can I ask, why are you putting different objects into the same collection? What's the benefit to you?
If you want a collection which can add objects of any type then List<object> is the most appropriate type.
Collections in earlier versions of C# (not generics) can contain any kind of objects. If they're value type, they will be boxed into object.
When you need to use them, you can just cast it to the original type.
You may use List<Type> to hold the type information, if that's what you want. And Type[], Hashtable, etc. are also fine. You can use typeof operator to get the type or use Object.GetType().
Also check out Dynamic type.
http://msdn.microsoft.com/en-us/library/dd264736.aspx
It will basically do the same thing.
My Suggestion:
public class ParamValue
{
object value = null;
public ParamValue(object val)
{
value = val;
}
public string AsString()
{
return value.ToString();
}
public int AsInt()
{
return int.Parse(value.ToString());
}
public int? AsNullableInt()
{
int n;
if (int.TryParse(value.ToString(), out n))
{
return n;
}
return null;
}
public bool AsBool()
{
return bool.Parse(value.ToString());
}
public bool? AsNullableBool()
{
bool b;
if (bool.TryParse(value.ToString(), out b))
{
return b;
}
return null;
}
}
public class Params
{
Dictionary<string, object> paramCol = new Dictionary<string, object>();
public void Add(string paramName, object value)
{
paramCol.Add(paramName, value);
}
public ParamValue this[string paramName]
{
get
{
object v;
if (paramCol.TryGetValue(paramName, out v))
{
return new ParamValue(v);
}
return null;
}
}
}
Use param class as a collectio to your values, you can convert the return to every type you want.
You could use a Tuple of Genric Types
public Tuple<T, T> MySuperMethod()
{
int number = 1;
string text = "Batman";
return new Tuple<int, string>(number, text);
}
The .NET Framework directly supports tuples with one to seven
elements. In addition, you can create tuples of eight or more elements
by nesting tuple objects in the Rest property of a Tuple object.
https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.100).aspx