views:

96

answers:

5

I've been doing some reading up on XML serialization, and from what I understand, It is a way to take an object and persist the state in a file. As for the implementation, it looks straight forward enough, and there seems to be a load of resources for applying it. When should XML serialization be used? What are the benefits? What are situations that are best helped by using this?

A: 

this is just from personal experiences - XML serialization is good for web services. Also, if you want to modify (or allow the modification of) the object/file that you're storing to without using the application that you're writing (i.e third party app), XML can be a good choice.

aggietech
+1  A: 

Its good for communication between disparate systems. E.G. take a Java app and a C# app and allow them to communicate via a webservice with serializeable XML objects. Both apps understand XML and are shielded from the details of the other language. And yes while you could fire strings back and forth, XML gives us strong typing and schema validation.

P.Brian.Mackey
Very interesting. So it should be used to communicate with other languages and provides a good way of validating data. Thank you!
CaffeineZombie
+2  A: 

You've answered a little bit of the question in your post. It's great for persisting the state of an object. I've used it in applications for saving user settings. It's also a great way to send data to other systems, since it is standardized. An important thing to remember is that it is easily human readable. This can either be a good or bad thing depending on your situation. You might want to consider encrypting it, or using encrypted binary serialization if you don't want someone else to be able to understand it.

EDIT:
Another gotchya worth mentioning is that the .NET implemented XMLSerializer only serializes public members in a object. If you need to persist private or protected members, you will either need to use a customized serializer or use another form of serialization.

blachniet
Thank you, this is precisely what I was looking for.
CaffeineZombie
+2  A: 

The .NET XmlSerializer class isn't the only way to persist an object to XML. The newer DataContractSerializer is faster, and also allows an object to be persisted to a binary form of XML, which is more compact.

The XmlSerializer is only getting limited bug fixes these days, in part because so much code depends on the precise details of how it works, in part because it is associated with ASMX web services, which Microsoft considers to be a "legacy technology".

This is not the case with the DataContractSerializer, which continues to be a vibrant and important part of WCF.

John Saunders
Alright...but when would you use this? It is good to know about the different versions, thank you for making me aware. So from what you're saying, invest my time with DataContractSerializer?
CaffeineZombie
Yes, unless you need full control over the format of the XML, stick with the `DataContractSerializer`. It's faster and more flexible. For instance, it can serialize private fields, which the `XmlSerializer` will just ignore.
John Saunders
A: 

I send an array of Objects of type class I wrote, using HttpWebRequest, so I cant send it as an object , because im mixing HttpWebRequest + Soap (that Im writing), and in Soap you cant send a non predefined Objects as String, int , ... .

so I used XML serialization to convert my object to an XML string and send it through my HttpWebRequest .

Arrabi