I ran in to a fellow programmer and was discussing a method i needed to write, and in an OOP aspect, the a Dictionary<T,U> is perfect. But, i voiced concerns about the XML size and structure that it is translated to during serialization. So my buddy, in a very direct manner, said i should be using a wrapper object that contains the key and value, and return a list of them instead of a dictionary. Are there some .NET objects that just shouldnt be serialized over SOAP, and simpler, custom objects should be created instead?
The main things you need to worry about are:
Don't send unnecessary information.
Dont make too many service calls.
Try to balance size of data against number of calls (optimally reduce both of these to a minimum).
As a rule most people avoid passing data structures which contain complicated logic, such as Dictionary.
Serializing a List is fine (it will be serialized as an IEnumerable).
Don't feel that your data objects have to look like your Entity objects - think of packets of information rather than Entities. When you receive the data at the client end you should convert it into Entity objects.
Related
I have serialized a C# class using protobuf-net. The resultant byte array is stored in a database. This is for performance reasons and I probably won't be able to change this design. The C# language doesn't make it possible to prevent classes being modified, and the class structure being passed in for deserialization with time may require changes that will not match that used for serialization, causing retrieval to fail.
Other than the wrapper technique suggested here, is there a pattern or technique for handling this kind of problem?
The only othe technique that comes to my mind is to version the classes that need to be deserialized in order to not loose anything when you need to make some changes. When you serialize an instance of those classes, you have to serialize also the version of the class (it could be a field of the the class itself).
I don't think this is the best solution but a solution.
The versioning strategy could become very difficult to manage when the changes (and the versions) start to grow.
A project I am working on is consuming Web API's returning heterogeneous JSON, I don't understand why a webservice API would need to return different object graphs, but that is what is being returned.
My questions are
Is it usual/common practice to return different object graphs by the same api? By different object graph I mean a varying complex object that might have or not have some other complex objects as properties. It would have seem reasonable if the same properties returned for every call, either having a null value or a complex object as their values, but the properties being completely omitted in the response makes it hard to have a C# class to desrialise against.
How is JSON heterogeneous (de)serialisation handled in C#? Is reflection and run time code generation preferred method for this? or using dynamic/expando object?
It makes sense for some APIs to return different objects when some fields that happen to be complex objects are omitted because they do not contain information sometimes, or an endpoint returns different objects based on different parameters. Not sure if there are other cases.
As for different JSON, you have to know a little bit about what data is returned by the API and getting at least the data you need. You can use Json.NET and deserialize to a class or to a dynamic object if you are not entirely sure what to expect or don't want to create a class for it.
I also advise to read the API documentation, or do some sort of (boundary?) testing with the parameters to figure out what data to expect.
I want to deserialize an object graph in C#, the objects in the graph will have object and collection properties, some of the properties may be private, but I do not need to worry about cyclic object references. My intent is to use the deserialized object graph as test data as an application is being built, for this reason the objects need to be able to be deserialized from the XML prior to any serialization. I would like it to be as easy as possible to freely edit the XML to vary the objects that are constructed. I want the deserialization process not to require nested loops or nested Linq to SQL statements for each tier in the object graph.
I found the DataContractSerializer lacking. It can indeed deserialize to private fields and properties with a private setter but it appears to be incredibly brittle with regard to the processing of the XML input. All it takes is for an element in the XML to be not in quite the right order and it fails. What's more the order it expects the data to be declared in does not necessarily match the order the object members are declared in the class declaration, making it impossible to determine what XML will work without having the data in the objects to start with so that you can serialize it and check what it expects.
The XmlSerializer does not appear to be able to serialize to non-public data of any type.
Since the purpose is to generate test input data for what might be quite simple applications during development I'd rather not have to resort to heavyweight ORM technologies like Entity or Nhibernate.
Is there a simple solution?
[Update]
#Chuck Savage
Thanks very much for your reply. I'm responding in this edit due to the comment character limit.
In the technique you suggested the logic to deserialize each tier of the object hierarchy is maintained in each class, so in a sense you do have nested Linq to SQL just spread out across the various classes involved. This technique also maintains a reference to the XElement from which each object gets its values in each class, so in that sense it isn't so much deserialized as just creating a wrapper around the XML. In the scenario I have in mind I'd ideally like to be deserializing the actual business objects the application will use so an XML wrapper type object like this wouldn't work very well since it would require a distinctly different implementation for test usage compared to production usage.
What I'm really after is something that can do something akin to what the XmlSerializer can do, but which can also deserialize private fields, (or at least properties with no setter). The reason being that the XmlSerializer does what it does with minimal impact on the 'normal' production use of the classes involved (and hence no impact on their implementation).
How about something like this: https://stackoverflow.com/a/10158569/353147
You will have to create your own boilerplate code to go back and forth to xml, but with the included extensions that can be minimized.
Here is another example: https://stackoverflow.com/a/9035905/353147
You can also search my answers on the topic with: user:353147 XElement in the StackOverflow search.
The .NET Framework ships with System.Runtime.Serialization.Json.DataContractJsonSerializer and System.Web.Script.Serialization.JavaScriptSerializer, both of which de/serialize JSON. How do I know when to choose one of these types over the other? MSDN doesn't make it clear what their relative advantages are.
We have several projects that consume or emit JSON, and the class selected for each thus far has depended on the opinion of the primary dev on each project. Some are simple, two have complex logic regarding producing managed types from JSON (the types do not map closely to the streams) but don't have any emphasis on speed, one requires speed. None interact with WCF, at least as of now.
While I'm interested in alternative libraries, I am hoping that somebody might have an answer to my question too.
The DataContractJsonSerializer is intended for use with WCF client applications where the serialized types are typically POCO classes with the DataContract attribute applied to them. No DataContract, no serialization. The mapping mechanism of WCF makes the sending and receiving very simple, but only if your platform is homogeneous. If you start mixing in different toolsets, your program might go sideways.
The JavaScriptSerializer can serialize any type, including anonymous types (one way), and does so in a more conformant way. You lose the "automagic" of WCF, but you gain more integration options.
As you can see by the comments, there are a lot of options out there for AJAX serialization, and to address your speed vs. maintainability questions, it might be worth investigating them to find a solution that meets the needs of all the teams, to reduce maintainability issues in the long term as everybody does things their own way.
2014-04-07 UPDATE:
I suggest using JSON.NET if you can. See http://james.newtonking.com/json Feature Comparison for a review of the 3 libraries considered in this question.
2015-05-26 UPDATE:
If your company requires the use of commercially licensable products, or you need every last bit of performance, you may also want to check out https://servicestack.net/.
Both do approximately the same but using very different infrastructure thus applying different restrictions on the classes you want to serialize/deserialize and providing different degree of flexibility in tuning the serialization/deserialization process.
For DataContractJsonSerializer you must mark all classes you want to serialize using DataContract atrtibute and all members using DataMember attribute. As well as if some of you classes have enum members, then the enums also must be marked as DataContract and each enum member - with EnumMember attribute.
Also DataContractJsonSerializer allows you fine control over the whole process of serialization/deserialization by altering types resolution logic and replacing the types you serialize with surrogates.
For JavaScriptSerializer you must provide parameterless constructor if you plan on deserializing objects from json string.
For me, I usually use JavaScriptSerializer in presentation logic, where there's a simple model I want to render in Json together with page, without additional ajax requests. And I even usually don't have to deserialize them back to c# - so there's no overhead at all. But if it's persistence logic, where I want to save objects into a data store (usually no-sql storage), to load them later, I prefer using DataContractJsonSerializer because the overhead of putting attributes is worth of flexibility in the serialization/deserialization process tuning, especially when it comes to loading of serialized data into the objects of the newer version, with updated definitions
Personally, I think that DataContractJsonSerializer reeks of over-engineering. I'd skip it and go with JavaScriptSerializer. In the event where JavaScriptSerializer isn't available, you can use FridayThe13th (a library I wrote ;p).
I'm exposing Data objects via service oriented assembly (which on future usages might become a WCF service).
The data object is tree designed, as well as formed from allot of properties.
I now want to expose data flow warnings and wondering what's the best way to do it having to things to consider: (1) seperation (2) ease of access. On the one hand, i want the UI team to be able to access a fields warnings (or errors) without having them mapping the field names to an external source but on the other hand, i don't want the warnings "hanged" on the object itself (as i don't see it a correct design).
I tought of creating a new type of wrapper for each field, that'll expose events and they'll have to register the one's they care about (but totally not sure)
I'll be happy to hear your thoughts.
Thank you very much!
IDataErrorInfo (re: comments on the question) is an interface. You can do whatever the heck you want. Said another way, it's a concept that does sound like it's a good place to start.
IDataErrorInfo's properties could simply be accessors to a dictionary-like structure/object that contains field:errorMessage pairs. The dictionary has the field name as a string - no references to real Data objects at all.
I can see DataError objects, if you will, mirroring the Data object hierarchical structure with IDataErrorInfo implemented at each level. Given this common interface you can recursively drill down getting error message sets for any arbitrary level of the Data.