是否可以使用具有 ISerialized 机制的 ProtoBuf-Net?
我们有一个项目,通过实现 ISerialized 并使用 BinaryFormatter 来使用序列化。我们正在转向没有 BinaryFormatter 类的 .net Compact。我想知道我们是否可以使用 ProtoBuf-Net。我们可以指示 ProtoBuf-Net 使用 GetObjectData() 进行序列化吗?具体来说,我想了解如何使用 Serializer.Serialize(SerializesInfo, ISerializable) 函数。
额外 我查看了源代码,发现虽然函数
Serializer.Serialize(SerializedInfo, T t) 其中 T 是 ISerialized 根本不使用 T is ISerialized 约束。为什么 T 被声明为 ISerialized?
We have a project which uses serialization by implementing ISerializable and using BinaryFormatter. We are moving to .net compact which do not have BinaryFormatter class. I was wondering if we can use ProtoBuf-Net. Can we instruct ProtoBuf-Net to use GetObjectData() for serialization? Specifically, I want to find out how to use Serializer.Serialize(SerializableInfo, ISerializable) function.
Added
I looked at the source code and I see that though the function
Serializer.Serialize(SerializableInfo, T t) where T is ISerializable
doesn't use the constraint T is ISerializable at all. Why was T declared to be ISerializable?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
ISerialized
支持(目前)作为一种机制存在,用于将 protobuf-net 注入到使用BinaryFormatter
的现有 API 中间 - 例如,您可以这样做来减少.NET 远程处理或(序列化)会话状态的开销。但是,这仍然会在BinaryFormatter
包装器中间产生 pb-net BLOB(特别是,bf 标头指定具体类型 assembly-qualfied-name)。关于约束的问题 - 这只是为了帮助指导使用;该 API 仅打算用作通过
ISerialized
注入BinaryFormatter
的一部分。否则,最好只使用基于Stream
的 API。如果您正在查看 CF,那么
BinaryFormatter
当然不再有用,但基于Stream
的 API 很好。它适用于 CF,但您应该注意,对于具有大量类的模型,目前 CF 上存在一些由于过度使用泛型而导致的故障(“缺少方法”或类似的情况)。好消息是我正在取得良好进展 在一些重构上放弃了这一点,使其在较小的框架上更加稳定。The
ISerializable
support exists (at the moment) as a mechanism for injecting protobuf-net into the middle of existing APIs that useBinaryFormatter
- for example, you can do this to reduce the overhead of .NET remoting or (serialized) session-state. However, this still results in a pb-net BLOB in the middle of aBinaryFormatter
wrapper (in particular, the bf header specifies the concrete type assembly-qualfied-name).Re the question about the constraint - that is simply to help guide usage; that API is only intended to be used as part of this injection into
BinaryFormatter
viaISerializable
. Otherwise it is preferred to just use theStream
based API.If you are looking at CF, then of course
BinaryFormatter
ceases to be useful, but theStream
based API is fine. It works on CF, but you should note that for models with lots of classes there are currently some glitches on CF caused by the overuse of generics ("missing method" or some-such). The good news is that I'm making good progress on some refactoring that ditches this, making it much more stable on the smaller frameworks.