ran*_*ude 0 java serialization deserialization
问题:开发人员创建自己的序列化格式有多常见？具体来说,我使用java本质上将对象作为带有标记的巨型字符串发送以分隔变量.
我的逻辑:我选择了这个,因为它几乎消除了语言依赖性(忽略了java的修改过的UTF-8),你也没有对象版本问题,如果使用java的序列化,接收端必须具有完全相同的版本对象,因此在旧版本上运行的客户端将无法接收任何对象数据.代码不是太难看,而且看起来还不错,但我想我的问题是这个实例的最佳实践是什么？这是个人项目.
其他已知的选择:好的,我只是在处理序列化一个对象以通过网络发送它并且遇到了谷歌协议缓冲区.序列化对象的标准化程度如何？我基本上有三种方法可以做到这一点.(我将在这里讨论java,因为这就是我所做的)1)使用语言的(java)本机序列化类2)使用你自己的方式序列化对象可能使用字符串和标记3)使用Protocol Buffers或一些其他已知的格式(JSON,XML等)
根据我的收集,你在串行化时基本上有3个主要目标:1)速度/效率/大小2)语言独立3)版本接受(在旧版本的代码仍然可以接受新版本的部分和副本反之亦然)
大多数大型软件项目使用协议缓冲区吗？如果您的客户端是资源少得多的移动设备,它会改变吗？
如果您使用标准格式(JSON,XML,甚至是原型缓冲区),那么通过集成点扩展应用程序的机会将会更多.但如果它只是内部的,那么做一切都很容易.就个人而言,我创建了一个专用的持久代理类,它代表给定对象的序列化形式.然后使用writeReplace和readResolve,使用最有意义的方法(用于线上实时传输的Java序列化,用于长期持久性的xml)序列化该对象.随着类的发展,我可以创建持久代理的全新实现,向代理添加版本控制等......视情况而定.我相信Bloch在Effective Java中讨论了这种模式.
至于提出纯粹的从头开始的线程协议,它实际上取决于性能对应用程序的重要程度.与大多数事情一样,您可以越多地利用标准库/协议,您就可以越快地获得新代码.当我看到序列化/等涉及的大量代码时......我通常认为这是一种代码味道,并且非常关注它是否合理.只需我0.02美元.
PS - 有人发布了关于图表的问题......这实际上是我故意避免标准序列化的一个领域.Java能够序列化复杂的图形并不是很好 - 如果图形甚至是远程复杂的,你最终会遇到堆栈溢出问题(hah).在这些情况下,持久代理非常非常重要.
问题:开发人员创建自己的序列化格式有多常见？
假设你的意思是从头开始创建它,那么答案"非常罕见".
另外,我说一般来说这不是"最佳做法".在大多数情况下,现有的常用替代方案之一(Java序列化,JSON,XML等)提供了一个很好的解决方案.
海事组织,你应该只考虑"滚你自己的"格式(和实施相应的序列化/反序列化代码)如果你有一个明确的要求这样做,或者如果你有明确的证据表明现有的替代品将无法正常工作."XYZ缓慢"的民间智慧并不足以证明.
| 归档时间： |
|
| 查看次数： |
1558 次 |
| 最近记录： |