基于内置BinaryFormatter的.Net序列化有哪些不足？

Question

基于内置BinaryFormatter的.Net序列化有哪些不足？（性能，灵活性，限制）如果可能，请在回答中附上一些代码。例：序列化的自定义对象必须使用[Serializable]属性修饰或实现ISerializable接口。不太明显的例子：匿名类型不能序列化。

Answer 1

数据的版本控制通过属性进行处理。如果您不担心版本控制，那么这没问题。如果是的话，这是一个巨大的问题。

属性方案的麻烦在于，它在许多琐碎的情况下（例如添加新属性）都非常流畅，但是当您尝试执行将两个枚举值替换为不同的新枚举值（或任何其他枚举值）时，它会很快崩溃长期持久性数据附带的常见方案数）。

我可以介绍很多麻烦的细节。最后，如果需要的话，编写自己的序列化程序非常简单。

Answer 2

我同意最后一个答案。性能相当差。最近，我的编码团队完成了将模拟从标准C ++转换为C ++ / CLI的工作。在C ++中，我们有一个手写的持久性机制，该机制运行良好。我们决定使用序列化机制，而不是重写旧的持久性机制。
在内存占用量介于1/2和1 Gig之间的大多数旧模拟中，大多数对象具有指向其他对象的指针，并且在运行时具有1000个对象，在一分钟之内将保留到大约10到15 Meg的二进制文件。从文件还原是可比较的。
使用相同的数据文件（并排运行），C ++ / CLI的运行性能大约是C ++的两倍，直到我们进行持久性处理（新版本中的序列化）为止，编写过程需要3到5分钟，序列化文件的大小约为10到20。序列化文件的大小约为旧文件的5倍。基本上，我们看到读取时间增加了19倍，写入时间增加了5倍。这是不可接受的，我们正在寻找纠正此问题的方法。

在检查二进制文件时，我发现了一些问题：1.所有类型的类型和程序集数据均以明文形式编写。这在空间上是无效的。2.每种类型的每个对象/实例都写入了膨胀的类型/装配体信息。我们在手保持机制中所做的一件事是写出了一个已知的类型表。在发现书面类型时，我们在此表中查找了它的存在。如果不存在，则会使用类型info创建一个条目，并分配一个索引。然后，我们将infor类型作为整数传递。（类型，数据，类型，数据）此“技巧”将极大地减少大小。这可能需要两次处理数据，但是可以开发“即时”流程，从而除了将其添加到表中，推送到数据流之外，

我希望重新实现一些核心序列化以这种方式对其进行优化，但是，可惜这些类都是密封的！我们可能仍未找到捷径。