我应该将gRPC protobuf消息转换为DTO吗？- 最佳实践

Question

最近，我开始使用gRPC消息与微服务进行交互。直到现在，我一直在使用REST API和DTO来保持代码中的解耦和封装性。

现在我正在使用gRPC protobuf消息时，我开始思考这里的最佳实践。在大声思考时，我会说，在应用程序的入口处获取消息时，最好将其转换为DTO，以保持gRPC protobuf消息与代码本身的解耦，但从另一个角度来看，我只是将对象转换为对象，想知道是否有必要进行这些开销。

期待您对此问题的想法。

- USer22999299

Answer 1

这要看您的需求以及服务需要多么解耦（长期而言）。据我所知，一些服务/人甚至倾向于将 proto 直接写入数据库中 （即以 proto-string/byte string 或 byte[] 形式），以减少映射开销和出于其他原因 我猜测。

话虽如此，就个人而言，我认为 领域模型 和 数据传输对象（Protobuf 消息） 应尽可能分离。因此，最好为请求和响应进行额外的映射，这将有助于未来更改 IDL 或 proto 定义。

如果您完全依赖于资源/API 层实现-在您的情况下是 gRPC，即使是小的库更新也可能会导致问题，并且需要查找使用了 proto 模型的所有位置会很麻烦

此外，它可以帮助您轻松适应更改，例如，如果您的系统选择完全依赖于另一个 API 架构

最后，我认为没有硬性规定要遵循，但这完全取决于您的需求，但最好将其转换为自己的模型，而不是直接使用它，这允许您更好地控制 API 层和业务层的隔离，并且在长期而言非常重要。

- Paritosh Bhattarai