0

问题：开发人员创建自己的序列化格式有多普遍？具体来说，我使用 java 本质上将对象作为带有标记的巨大字符串发送来分隔变量。

我的逻辑：我选择这个是因为它几乎消除了语言依赖性（忽略 java 修改后的 UTF-8），而且你没有对象版本问题，如果你使用 java 的序列化接收端必须有完全相同的版本对象，因此在旧版本上运行的客户端将无法接收任何对象数据。代码并不太难看，而且读起来还可以，但我想我的问题是这个实例的最佳实践是什么？这是针对个人项目的。

其他已知选择：好的，我只是在序列化一个对象以通过网络发送它，并且遇到了谷歌的协议缓冲区。序列化对象的标准化程度如何？我基本上遇到了三种方法来做到这一点。（我将在这里谈论 java，因为这就是我所做的） 1）使用语言的（java 的）本机序列化类 2）使用你自己的方式序列化对象，可能使用字符串和令牌 3）使用协议缓冲区或其他一些已知格式（JSON、XML 等）

根据我收集到的内容，您在序列化时基本上有 3 个主要目标：1）速度/效率/大小 2）语言独立性 3）版本接受（旧版本的代码仍然可以接受新版本的部分内容，反之亦然反之亦然）

大多数大型软件项目都使用协议缓冲区吗？如果您的客户端是资源少得多的移动设备，它会改变吗？

4

4 回答 4

6

如果您使用标准格式（JSON、XML 甚至 proto 缓冲区），将有更多机会通过集成点扩展您的应用程序。但如果它只是内部的，那就做简单的事。就个人而言，我创建了一个专用的持久代理类，它表示给定对象的序列化形式。然后使用 writeReplace 和 readResolve 使用最有意义的任何方法（用于在线实时传输的 Java 序列化，用于长期持久性的 xml）序列化该对象。随着类的发展，我可以创建持久代理的全新实现，向代理添加版本控制等......视情况而定。我相信 Bloch 在 Effective Java 中讨论了这种模式。

至于提出一个纯粹从头开始的协议，它实际上取决于性能对应用程序的重要性。与大多数事情一样，您可以利用的标准库/协议越多，您就可以越快地获得新代码。当我看到大量涉及序列化/等的代码时......我通常认为这是一种代码味道，并密切关注它是否合理。只是我的 0.02 美元。

PS - 有人发布了一个关于图表的问题......这实际上是我有意避免标准序列化的一个领域。Java 序列化复杂图的能力不是很好——如果图很复杂，你最终会遇到堆栈溢出问题（哈哈）。在这些情况下，持久代理非常非常重要。

于 2011-01-27T02:32:32.400 回答
5

问题：开发人员创建自己的序列化格式有多普遍？

假设您的意思是从头开始创建它，那么答案是“非常罕见”。

另外，我想说一般来说这不是“最佳实践”。在大多数情况下，现有的常用替代方案之一（Java 序列化、JSON、XML 等）提供了很好的解决方案。

IMO，如果您有明确的要求，或者您有明确的证据表明现有的替代方案不起作用，您应该只考虑“滚动您自己的”格式（并实现相应的序列化/反序列化代码） 。“XYZ 速度慢”的民间智慧是不充分的证据。

于 2011-01-27T03:41:33.843 回答
2

几件事情立刻浮现在我的脑海：

  • 在每条消息或连接协商中包含版本号。它将使您免于头疼。最好让发送者知道接收者支持什么版本。

  • 除非您发送自然是二进制的数据（图像、声音），否则请使用可读的纯文本 (UTF-8) 格式。这将有助于解决很多问题。我会坚持使用 JSON，但它可能不是您的最佳选择。XML 的开销很大。

  • 如果您的消息足够长，您可以尝试使用一些众所周知的算法来压缩它们，例如 gzip (GZIPOutputStream)。

如您所见，这些步骤促进了服务器和可能的客户端之间的格式开放和松散耦合。没有人知道您的客户将来必须使用什么技术：关心制作 iPhone 客户端吗？HTML5+JS 客户端？服务器同上:)

于 2011-01-27T02:39:48.793 回答
0

对于结构化数据 XML，JSon 很可能是最佳选择。但是对于简单的平面记录，我建议您考虑使用 CSV。您可能会发现它的实现更简单/更快。如果您有大量记录，则它们可以更容易地管理一口井。例如加载到电子表格中

于 2011-01-27T07:01:03.383 回答