内置的基于 BinaryFormatter 的 .Net 序列化有哪些不足? [英] What are the deficiencies of the built-in BinaryFormatter based .Net serialization?

问题描述

基于内置BinaryFormatter的.Net序列化有哪些不足?(性能、灵活性、限制)

What are the deficiencies of the built-in BinaryFormatter based .Net serialization? (Performance, flexibility, restrictions)

如果可能，请附上一些代码.

Please accompany your answer with some code if possible.

示例:

被序列化的自定义对象必须用 [Serializable] 属性修饰或实现 ISerializable 接口.

不太明显的例子:

匿名类型无法序列化.

推荐答案

如果你的意思是 BinaryFormatter:

• 基于字段，非常不支持版本；更改私有实现细节，它会中断(即使只是 将其更改为自动实现的财产)
• 与其他平台不兼容
• 对新领域不太友好
• 特定于程序集(元数据已烧入)
• 特定于 MS/.NET(也可能特定于 .NET 版本)
• 不是混淆安全的
• 不是特别快，或者输出很小
• 不适用于轻量级框架 (CF?/Silverlight)
• 有一个令人沮丧的习惯，就是把你没想到的东西拉进来(通常是通过events)

我在这方面花了很多时间，包括为 .NET 编写 Google 的协议缓冲区"序列化 API 的(免费)实现；protobuf-net

I've spent lots of time in this area, including writing a (free) implementation of Google's "protocol buffers" serialization API for .NET; protobuf-net

这是:

• 输出更小、速度更快
• 与其他实现交叉兼容
• 可扩展
• 基于合同
• 混淆安全
• 独立于程序集
• 是一个开放的文档化标准
• 适用于所有版本的 .NET(注意:未在 Micro Framework 上测试)
• 具有插入 ISerializable(用于远程处理等)和 WCF 的钩子

• smaller output and faster
• cross-compatible with other implementations
• extensible
• contract-based
• obfuscation safe
• assembly independent
• is an open documented standard
• works on all versions of .NET (caveat: not tested on Micro Framework)
• has hooks to plug into ISerializable (for remoting etc) and WCF

这篇关于内置的基于 BinaryFormatter 的 .Net 序列化有哪些不足?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！