我有项目 A 和项目 B。它们可能使用不同的编程语言。
项目 A 使用 proto 文件公开 API，项目 B 将使用该文件以项目 B 使用的编程语言生成 API。
但是原型文件存储在哪里？使用 protobuf 的传统方法是什么？您是否将从 proto 文件生成的文件添加到版本控制中？
如果您在项目 A 和项目 B 中都存储了 proto 文件的副本，那么如果项目 A 更改了其 API，那么项目 B 就必须将它们复制过来。当有很多项目使用项目 A 公开的 API 时，这种方法效果不佳。
如果您有一个单独的项目（项目 C）包含共享的原始文件，则可以解决上述问题。那么如何从项目 A 和项目 B 生成 proto 文件呢？
我建议存储.proto文件位于单独的项目中。这些是两个项目之间的合同，它们不一定属于任何一个项目“拥有”。将它们存储在单独的项目中为两个项目成员协商文件更改提供了中立的基础 - 例如通过拉取/合并请求流程，其中可能有来自两个项目的成员充当审阅者。
至于从原始文件生成代码，我可能会在需要它们的项目中这样做。所以在你的例子中，项目 C 只包含.proto文件，项目 A 和 B 将拉取.proto文件并生成他们需要的代码。我觉得必须是这样，因为项目 A 和 B 正在使用 protobuf 生成的代码。如果代码是在项目 C 中生成的，那么项目 A 和 B 仍然需要提取生成的代码才能使用它，并且由于项目 C 在技术上与 A 和 B 分离，因此需要使用哪些语言并不明显。生成 - 全部？只需要2个吗？
通过创建项目 C，您正在创建一个可以容纳更多内容的地方.proto其他项目的文件。展望未来，您可能会有许多共享公共基本消息类型的项目。要管理具有许多互连项目的体系结构，尝试合并消息定义非常有意义，如果每个项目都维护自己的定义，这将很困难/不可能，如果存在重复副本，情况会更糟（正如您所说）。将它们存储在一个位置允许新项目拾取现有定义并扩展它们（在进化指南内），并允许更严格地管理和维护一组定义，例如一组经验丰富的审阅者确保一切都一致且合理地完成 - 无论是从建模、命名空间还是版本控制的角度来看。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
