FUD（恐惧，不确定性和怀疑）被揭穿...-CSDN博客

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?"

是基尔凯郭尔(Kierkegaard)还是迪克·范·帕滕( Dick Van Patten )说的： “回想起来，最有可能发表声明的人最有可能被称为傻瓜？”

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.

抱歉，我并不是要在这里引起争议，也不要无视您的意图，但是这篇名为不使用[XML]序列化的九个理由的文章只是9种FUD。真诚的，废话。因为您看不到技术而对整个技术进行惩罚是FUD的最纯粹形式。这是反系列化，困扰着我的人民4000 er 4年。

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:

我从来都不是一个深入探讨这一问题的100个原因和54个原因的人。几个月前，我明智地将整个.NET与Java Top 100 List分开。但是，我必须单独对这些进行揭穿，但首先，要从整体上讲-如果鞋子被夹住，请不要穿。说真的没有适用于所有人的万事通技术，而XmlSerialization显然不是这位先生的技术。话虽如此：

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.

1.它迫使您以某种方式设计课程-是吗？和？它确实迫使您使用公共属性，因为序列化Privates需要向序列化程序提供一些非常具体的提示。在Whidbey中，私有可以序列化。当然，这现在对任何人都没有帮助。因此，请使用公众。

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.

2.微小的变化并不是面向未来的-从来没有宣称过。当然，在XML / XSD世界中，版本控制是一个更大的问题，而且正在解决中。如果您认为您的数据将发生变化，而您的应用程序将不会(不会重新编译)并且您的投资属于类(而不是架构)，那么XmlSerialization不适合您。您当然可以像我们一样使用XmlAnyElement和XmlAnyAttribute属性防止微小的更改。

3. It is not future-proof for large changes - See above.

3.对于大的更改，它不是面向未来的-参见上文。

4. It is not future-proof for massive changes - For crying out loud...

4.大规模的变革并非面向未来-大声呐喊...

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.

5.它不安全-安全是一个重要的词。您的前门不安全。他提到创建了临时文件(我假设他指的是每个类型的临时序列化汇编，并且“磁盘上的文件会带来安全风险”)。除非您明确将其序列化到磁盘，否则数据永远不会接触磁盘。 XmlSerialization没有内在的安全或不安全感。这只是序列化。除了等待，它已序列化为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?

6.它效率低下-“ XML是冗长的”，这是正确的，并且并非适用于所有人。有人声称，当Type信息与数据一起存储时，就磁盘空间而言，序列化会变得很昂贵。好吧，以每场1美元的价格，我认为一些额外的尖括号不会打退堂鼓，但是的，它不是二进制序列化。就像人们认为TCP / IP有太多层一样，人们也喜欢XML。现在，似乎每个人都没有汗水(在Wintel盒上)进行字节顺序转换，这种情况在每个数据包向下几层时发生了，对吗？

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!

7.这是一个黑匣子-在.NET中进行过一段时间编程的任何人都会意识到没有黑匣子。如果您担心XmlSerialization是一个黑匣子(并且比平时更黑)，则将其打开。当您看到生成的代码时，这很简单。这并不是特别令人惊奇的事情或改变生活的方法，但是它将帮助您意识到您的任务要简单得多，因为您无需编写代码-它是为您自动生成的！

8. It is slow - Well, that's just specious.

8.太慢了-好吧，这只是似是而非。

9. It is weird - Ya, new things usually are.

9.很奇怪-嗯，通常是新事物。

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.

我是XmlSerialization的粉丝，并且是所有使我的工作更加轻松的爱好者。我们正在对正在进行的项目使用XmlSerialization。我已经在INETA的一些演讲中介绍了我们的一些技术。

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.

为什么我不担心＃的2到4？因为我的投资是在XSD上，并且因为我自动生成了C＃代码，测试用例，测试实例数据，Voyager(我们的eFinance Server)的自定义模板以及所有强类型集合和一些非常酷的属性voodoo(使用CodeSmith和pixie尘土) 。 XmlSerialization是一个细节。使用任何技术，都要使自己绝缘。 当我们转到Whidbey和[DataContracts]时，我们将更改一个代码生成模板并继续。

That makes the experience of writing a Banking UI on top of Voyager and ASP.NET a strongly-typed joy.

这使在Voyager和ASP.NET之上编写Banking UI的体验成为一种强烈的乐趣。