FUD (Fear, Uncertainty and Doubt) debunked...
Was it Kierkegaard or Dick Van Patten who said "He who is most likely to make declarative statements is most likely to be called a fool in retrospect?"
Sorry, I don't mean to be controversal here, and no disrespect intended, but this article entitled Nine Reasons Not To Use [XML] Serialization is just 9 kinds of FUD. Sincerely, it's crap. To impune an entire technology because you don't see a use for it is the purest form of FUD. It's antiserializationism and it's plagued my people for 4000, er, 4 years.
I've never been one to get into the whole 100 reasons of this and 54 reasons of that. I wisely stayed out of the whole .NET vs. Java Top 100 List thing a few months back. But, I have to debunk these singly, but first, in whole - If the shoe pinches, don't wear it. Seriously. There are no catch-all-works-for-everyone technologies and XmlSerialization clearly isn't the technology for this gentleman. That being said:
1. It forces you to design your classes a certain way - Yes? And? It does force you to use Public Properties, as serializing Privates would require giving some very specific hints to the serializer. In Whidbey privates can be serialized. Of course, that doesn't help anyone now. So, use publics.
2. It is not future-proof for small changes - And it never claimed to be. Certainly versioning is a bigger problem in the XML/XSD world, and it's being worked out. If you think your data will change and your application will not (you're not going to recompile) and your investment is in your classes (and not your schema) then XmlSerialization isn't for you. You can certainly protect against small changes with the XmlAnyElement and XmlAnyAttribute attributes, as we do.
3. It is not future-proof for large changes - See above.
4. It is not future-proof for massive changes - For crying out loud...
5. It is not secure - Secure is a big word. Your front door isn't secure. He mentions that temporary files are created (I assume he's referring to the temporary per-type serialization assembles, and that 'files on disk pose a security risk.'). Your data never touches the disk unless you explicitly serialize it to disk. There's nothing inherently secure or insecure about XmlSerialization. It's simply serialization. Except, wait for it, it's serialized as XML.
6. It is inefficient - 'XML is verbose,' true, and it's not for everyone. The claim is made that when Type information is stored along with the data it makes serialization expensive in terms of disk space. Well, at $1 a gig, I think a few extra angle brackets won't break the back, but yes, it's not binary serialization. Just as folks thought that TCP/IP had too many layers, folks thing XML does. Noone seems to sweat the endian-switching (on Wintel boxes) that happens a few layers down with every packet now, do they?
7. It is a black box - Anyone who has programmed in .NET for a while realizes that there ARE no black boxes. If you are concerned that XmlSerialization is a black box (and somehow blacker than usual) then open it up. It's pretty straightfoward when you see the generated code. It's not particularly amazing or life altering, but it will help you realize how much simpler your task is since you didn't have to write the code - it was autogenerated for you!
8. It is slow - Well, that's just specious.
9. It is weird - Ya, new things usually are.
I am a fan of XmlSerialization, and I'm a fan of anything that makes my job easier. We're using the hell out of XmlSerialization on a project I'm on. I've presented some of our techniques at some INETA talks.
Why am I not worried about #'s 2 through 4? Because my investment is in XSDs and because I autogenerate (with CodeSmith and pixie dust) C# code, test cases, test instance data, custom templates for Voyager (our eFinance Server) as well as all our strongly typed collections and some very cool property voodoo. XmlSerialization is a detail. With any technology, insulate yourself. When we move to Whidbey and [DataContracts] we'll change one code generation template and move on.
That makes the experience of writing a Banking UI on top of Voyager and ASP.NET a strongly-typed joy.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Give google a couple of days to catch up, and you'll have a nice new Googlewhack.
The technology itself is certainly useful, no doubt about that. My gripe is when you must design an object model around the XML Serialization gotchas for trivial reasons that have nothing to do with the application/library you're writing. Specifically, I've been on projects where virtually every object had to be XML Serializable so you could view the object graph in the debug window or in a log. This may not sound like a big deal, but trust me, it really compromises the design and literally gives me headaches.
Again, it's very useful when the solution fits the problem. I'm using it heavily in an application utilizing WSE 2 for inter-machine communication. Being able to define classes that can be deserialized into .NET objects from XML fragments that originated _anywhere_ is huge.
Up with XML Serialization! Down with its misuse!
Marcie
"Why am I not worried about #'s 2 through 4? Because my investment is in XSDs and because I autogenerate (with CodeSmith and pixie dust) C# code, test cases, test instance data, custom templates for Voyager (our eFinance Server) as well as all our strongly typed collections and some very cool property voodoo. XmlSerialization is a detail. With any technology, insulate yourself. When we move to Whidbey and [DataContracts] we'll change one code generation template and move on."
Damn dude, you make me feel like I'm writing on stone tablets. And I mean that as a compliment. You give me something to asipre to. Thanks.
Comments are closed.
Love it, Scott.
you tell em. Serialization is excellent.
lb