是否可以使用具有 ISerialized 机制的 ProtoBuf-Net?

发布于 2024-08-20 23:57:49 字数 387 浏览 4 评论 0原文

我们有一个项目,通过实现 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

陌上芳菲 2024-08-27 23:57:49

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 use BinaryFormatter - 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 a BinaryFormatter 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 via ISerializable. Otherwise it is preferred to just use the Stream based API.

If you are looking at CF, then of course BinaryFormatter ceases to be useful, but the Stream 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文