我们将引入协议缓冲作为某些后端RPC服务的新传输方式。由于手动在类似对象之间传输数据存在阻力，我可以预见到协议缓冲实例会被传递到比RPC服务器接口更高的位置。
这是否是我应该避免的事情？将协议缓冲对象视为普通数据持有者安全吗？它具备快速高效地转换成二进制并进行转换的便利性。
我认为它作为生成数据对象的好方法的另一个原因是所需/可选字段的概念和自动生成的构建器接口。
2个回答
9
它们不太方便以这种方式使用，因为它们是不可变的 - 你可以传递构建器，但那会导致类型名称相当冗长。这也意味着你只能使用协议缓冲区支持的数据类型（和你自己的消息）。
这样做是安全的，但并不总是创建最好的设计。另一方面，有时这正是医生所开的药方 :)
我建议你进行实验 - 这里没有“一刀切”的方法。
- Jon Skeet
3
我认为它们是不可变的事实实际上有助于使用协议缓冲区，而不是伤害。它们是不可变的值对象，就像字符串一样。 - Laurence Gonsalves
在某些情况下，使用函数式编程风格编写代码确实有所帮助。这部分取决于问题本身和开发人员的能力 :) - Jon Skeet
Immutable在某些情况下确实很有帮助，出于未知原因，存在一些具有十几个或更多参数的公共构造函数，所有这些参数都被分配给final字段。建造者模式非常好，但每次编写都很繁琐和模板化。正确理解必需与可选逻辑也很棘手，如果省略了必需字段，则build()方法会失败。 - Mark Renouf
0
通常情况下，我会设计系统的各个层级，以便一个层级的实现细节不会泄漏到另一个层级中。虽然我没有直接使用过Google的Protocol Buffers，但听起来你想在传输和系统的更高层级中使用相同的表示方法。
如果你决定停止使用Protocol Buffers作为传输表示方法，那么换用其他方法会有多容易呢？
如果你决定停止使用Protocol Buffers作为传输表示方法，那么换用其他方法会有多容易呢？
- SteveD
1
这实际上是朝着这个方向迈出的一步。现在，一组接口规定了我们的数据层、后端RPC和某种程度上的RESTful Web服务层。痛苦。第一步是用协议缓冲区替换后端，以将其与其他部分解耦。但这是一个很好的观点。如果我只是把所有东西都切换到protobufs，那么我解耦的唯一事情就是客户端和RPC服务之间的链接，而所有其他层都将依赖于消息对象...不好。 - Mark Renouf
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接