Can someone tell me the difference between XmlSchemaType and XmlQualifiedName class. I'm bit confused when to choose which class. Actually I'm using IXmlSerializable interface for my class and to specify schema for this I used XmlSchemaProviderAttribute and specify the function which can return either XmlSchemaType or XmlQualifiedName. Both work fine and I successfully generate the proxy. but unable to find a consolidated analysis which one is to use in which condition.
As per Microsoft
XmlSchemaType Class:
The base class for all simple types and complex types.
XmlQualifiedName Class:
Represents an XML qualified name.
but I'm unable to understand the exact difference between these two.
After doing google and reading some article I've finally find the difference between these 2 and understand where to choose what?
There are 3 different types that can implement IXmlSerializable Interface
Content types
Element types
Legacy DataSet types
For content types we need to use XmlQualifiedName Class as return parameter (Method name specify in XmlSchemaProvider) and this will require that main root element of XSD will be the complextype.
For elements types we need to use XmlSchemaType Class. Here you can specify any root element in XSD.
For Legacy DataSet types we don't use XmlSchemaProvider attribute. Instead, they rely on GetSchema method for Schema generation.
I've found all this useful information from following MSDN link. A must read article for better understanding how Xml Serialization works in WCF.
Using the XmlSerializer Class
Related
What is the recommended (modern) approach for reusing types between different classes?
SAP does not recommend to collect constants in an interface, calling it a loosy way of declaring:
" anti-pattern
INTERFACE /dirty/common_constants.
CONSTANTS:
warning TYPE symsgty VALUE 'W',
transitional TYPE i VALUE 1,
error TYPE symsgty VALUE 'E',
persisted TYPE i VALUE 2.
ENDINTERFACE.
Does the same applies to types? What are the drawbacks or advantages I am not aware of?
Should I use use classes, interfaces for types or maybe type pools?
As the document you linked to says, you should not use an interface for constants because that way you are:
misleading people to the conclusion that constants collections could be "implemented".
Which is why they recommend to put constants into an ABSTRACT FINAL class.
ABSTRACT means that this class as itself can not be instantiated (like an interface) and FINAL that it can not be inherited from (unlike an interface). This clearly communicates to the user that this class only exists as a container for static things like CONSTANTS, CLASS-DATA, CLASS-METHODS and of course TYPES.
So the same argument can be used against interfaces which do nothing but serve as a container for types. When you create an INTERFACE for that sole purpose, then people might wonder how they are supposed to implement that interface. So you would put them into a CLASS instead.
Another alternative which is still worth considering IMO (especially if you consider to use any of those types in database tables) is to use the good old ABAP Dictionary. It was invented for exactly that purpose: To serve as a directory for global types.
Unfortunately it doesn't allow you to organize types into namespaces (not unless you are working for SAP or a SAP partner who is able and willing to go through the bureaucracy to register a worldwide unique namespace for every product). So you have to make sure that each type you create has a proper prefix so people know which application it belongs to. But there is a character limit for dictionary type names, so you have to keep them short.
Using a class as a container for the types of each application solves that problem. The class serves as a namespace, so your type names no longer need to be system-unique.
I'm trying to do some polymorphic deseralization of JSON using Jackson, however the list of subclasses is unknown at compile time, so I can't use a #JsonSubtype annotation on the base class.
Instead I want to use a TypeIdResolver class to perform the conversion to and from a property value.
The list of possible subclasses I might encounter will be dynamic, but they are all registered at run time with a registry. So I would appear to need my TypeIdResolver object to have a reference to that registry class. It has to operate in what is essentially a dependency injection environment (i.e I can't have a singleton class that the TypeIdResolver consults), so I think I need to inject the registry class into the TypeIdResolver. The kind of code I think I want write is:
ObjectMapper mapper = new ObjectMapper();
mapper.something(new MyTypeIdResolver(subclassRegistry));
mapper.readValue(...)
However, I can't find a way of doing the bit in the middle. The only methods I can find use java annotations to specify what the TypeIdResolver is going to be.
This question Is there a way to specify #JsonTypeIdResolver on mapper config instead of annotation? is the same, though the motivation is different, and the answer is to use an annotation mixin, which won't work here.
SimpleModule has method registerSubtypes(), with which you can register subtypes. If only passing Classes, simple class name is used as type id, but you can also pass NamedType to define type id to use for sub-class.
So, if you do know full set, just build SimpleModule, register that to mapper.
Otherwise if this does not work you may need to resort to just sharing data via static singleton instance (if applicable), or even ThreadLocal.
Note that in the end what I did was abandon Jackson and write my own much simpler framework based on javax.json that just did the kinds of serialisation I wanted in a much more straightforward fashion. I was only dealing with simple DTO (data transfer object) classes, so it was just much simpler to write my own simple framework.
Can someone point me to a good explanation of the criteria a class must meet to use the default deserializaton for Jackson?
I can do a post and supply a HashMap collection of string/jsonObjects, but it won't work with a dataset that contains the same information in a row. I tried implementing my own Deserializer but the response is always "Unprocessable Entity". I have been successful using specific classes, but I am trying to generalize my solution by passing a dataset.
Obviously I need a better understanding of what is happening! TIA!
It depends on rough type of your class. Jackson has specialized handling for:
Arrays of types
Collection implementations
Map implementations
Enums
Other
If type is none of first 4 categories, it will be considered "Other", and expected to follow Java Bean convention of either public fields, or getters and/or setters.
There also has to be a no-argument constructor (need not be public), or another constructor annotated with #JsonCreator -- expect that some public single-argument constructors (String, int/Integer, long/Long, boolean/Boolean) are also accepted when binding from JSON Scalar values.
But to get more information you really should share the actual exception you get: above is just the general idea of what is needed. Jackson can work with all kinds of classes, and is not particularly strict in how classes are defined. But it does have expectations on how various JSON Structures match with POJOs.
In my web method, I get an object of some third party C# entity class. The entity class is nothing but the DataContract. This entity class is quite complex and has properties of various types, some properties are collections too. Of course, those linked types are also DataContracts.
I want to serialize that DataContract entity into XML as part of business logic of my web service. I cannot use DataContractSerializer directly (on the object I receive in the web method) simply because the XML schema is altogether different. So the XML generated by DataContractSerializer will not get validated against the schema.
I am not able to conclude the approach I should follow for implementation. I could think of following implementation approaches:
LINQ to XML - This looks ok but I need to create XML tree (i.e. elements or XML representation of the class instance) manually for each type of object. Since there are many entity classes and they are linked to each other, I think this is too much of work to write XML elements manually. Besides, i'll have to keep modifying the XML Tree as and when the entity class introduces some new property. Not only this, the code where I generate XML tree would look little clumsy (at least in appearance) and would be harder to maintain/change by some other developer in future; he/she will have to look at it so closely to understand how that XML is generated.
XmlSerializer - I can write my own entity classes that represent the XML structure I want. Now, I need to copy details from incoming object to the object of my own classes. So this is additional work (for .NET too when code executes!). Then I can use XmlSerializer on my object to generate XML. In this case, I'll have to create entity classes and whenever third party entity gets modified, I'll have to just add new property in my class. (with XmlElement or XmlAttibute attributes). But people recommend DataContractSerializer over this one and so I don't want to finalize this unless all aspects are clear to me.
DataContractSerializer - Again here, I'll have to write my own entity class since I have no control over the third party DataContracts. And I need to copy details from incoming object to the object of my own classes. So this is additional work. However, since DataContractSerializer does not support Xml attributes, I'll have to implement IXmlSerializable and generate required Xml in WriteXml method. DataContractSerializer is faster than XmlSerializer, but again I'll have to handle the changes (in WriteXml) if third party entity changes.
Questions:
Which approach is best in this scenario considering performance too?
Can you suggest some better approach?
Is DataContractSerializer worth considering (because it has better performance over XmlSerilaizer) when incoming entity class is subject to change?
Should LINQ be really used for serialization? Or is it really good for things other than querying?
Can XmlSerializer be preferred over LINQ in such cases? If yes, why?
I agree with #Werner Strydom's answer.
I decided to use the XmlSerializer because code becomes maintainable and it offers performance I expect. Most important is that it gives me full control over the XML structure.
This is how I solved my problem:
I created entity classes (representing various types of Xml elements) as per my requirement and passed an instance of the root class (class representing root element) through XmlSerializer.
Small use of LINQ in case of 1:M relationship:
Wherever I wanted same element (say Employee) many times under specific node (say Department) , I declared the property of type List<T>. e.g. public List<Employee> Employees in the Department class. In such cases XmlSerializer obviously added an element called Employees (which is grouping of all Employee elements) under the Department node. In such cases, I used LINQ (after XmlSerializer serialized the .NET object) to manipulate the XElement (i.e. XML) generated by XmlSerializer. Using LINQ, I simply put all Employee nodes directly under Department node and removed the Employees node.
However, I got the expected performance by combination of xmlSerializer and LINQ.
Downside is that, all classes I created had to be public when they could very well be internal!
Why not DataContractSerializer and LINQ-to-XML?
DataContractSerializer does not allow to use Xml attributes (unless I implement IXmlSerializable). See the types supported by DataContractSerializer.
LINQ-to-XML (and IXmlSerializable too) makes code clumsy while creating complex XML structure and that code would definitely make other developers scratch their heads while maintaining/changing it.
Is there any other way?
Yes. As mentioned by #Werner Strydom, you can very well generate classes using XSD.exe or tool like Xsd2Code and work directly with them if you are happy with the resulting classes.
I'll pick XmlSerializer because its the most maintainable for a custom schema (assuming you have the XSD). When you are done developing the system, test its performance in its entirety and determine whether XML serialization is causing problems. If it is, you can then replace it with something that requires more work and test it again to see if there is any gains. But if XML serialization isn't an issue, then you have maintainable code.
The time it takes to parse a small snippet of XML data may be negligible compared to communicating with the database or external systems. On systems with large memory (16GB+) you may find the GC being a bottleneck in .NET 4 and earlier (.NET 4.5 tries to solve this), especially when you work with very large data sets and streams.
Use AutoMapper to map objects created by XSD.EXE to your entities. This will allow the database design to change without impacting the web service.
One thing that is great about LINQ to XML is XSD validation. However, that impacts performance.
Another option is to utilize LINQ and Reflection to create a generic class to serialize your object to XML. A good example of this can be found at http://primecoder.blogspot.com/2010/09/how-to-serialize-objects-to-xml-using.html . I am not sure what your XML needs to look like at the end of the day, but if it is pretty basic this could do the trick. You would not need to make changes as your entity classes add/remove/change properties, and you could use this across all of your objects (and other projects if stored in a utility DLL).
how does Serialization of objects works? How object got deserialized and a instance is created from serialized date without a call to any constructor?
I've kept this answer language agnostic since a language wasn't given.
When the object is serialized, all the require information to rebuild it is encoded in way which can be retrieved. This typically includes the type of the object, as well as the value of all the instance variables.
When the object is deserialized, an area in memory of the correct size is allocated and is populated using the serialized information such that the new object is identical to the serialized one.
The running program can then refer to this new object in memory without having to actually call the constructor.
There are lots of little details which this doesn't explain, but this is the general idea of serialization/deserialization.
Are you talking about Java? If so, serialization is an extralingual object creation mechanism. It's a backdoor that uses native code to create the object without calling any constructors. Therefore, when designing a class for serializability, you need to make sure that a class created through deserialization maintains the same invariants (key fields being initialized) as you would through the constructor path. A third way to create objects in Java is through cloning, and similar issues apply.
Cloning and serialization don't interact well with the use of final fields if you need to set the value of that field to something different than what is returned by clone or the deserialization process.
Josh Bloch's "Effective Java" has some chapters that explain these issues in more depth.
(this answer may apply to other languages too, but I've only used serialization in Java)
Regarding .NET: this isn't a definitive or textbook answer, and I might be all-out wrong...
.NET Serialization needs to be seperated out into Binary vs. others (XML or an XML derivitave typically). Binary serialization is mostly a black-box to me, but it allows the object to be serialized and restored in their current state. XML serialization typically only serialized the public fields/properties of an object, unless overriden by adding a custom ISerializable implementation.
In the case of XML serialization I believe .NET uses Reflection to determine which fields and properties get converted to their equivalent Elements. Adding an [XMLSerializable] attribute will implement a default behavior which can be adjusted by applying other attributes at the field level (such as [XMLAttribute]).
The metadata (which Reflection depends on) stores all the object members as well as their attributes and addresses, which allows the serializer to determine how it should build the output.