This post originated from an RSS feed registered with .NET Buzz
by Scott Hanselman.
Original Post: FUD (Fear, Uncertainty and Doubt) debunked...
Feed Title: Scott Hanselman's ComputerZen.com
Feed URL: http://radio-weblogs.com/0106747/rss.xml
Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios.
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.
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.
Previous Topic
