网关编程模型是新常态吗？

Question

因此，我一直试图使用中的网关包以外的包来查找教程和示例。我只找到了几个旧的，在1.4岁之前。此外，Hyperledger Fabric文档完全集中在网关模型上。

这让我想到了标题中的问题。这对我来说很有意义，因为我看不到使用SDK创建通道和部署链码的价值。因为我们仍然需要在CLI上执行管理任务:准备通道配置文件和通道创建事务，更不用说编写链码了。

最近是否有一种共识，完全在CLI上执行管理任务(创建通道、加入对等点和部署链码)，并将SDK与网关模型一起用于链码交互？

Answer 1

我们发现，有很多人使用“坏”的做法，试图在同一个客户端应用程序中混合管理任务和运行时任务。我们还复制了所有SDK中的管理功能，而且它在长期维护方面没有很好的扩展。

网关模型旨在简化与Fabric网络的运行时交互。需要很多可重复的"gorp“(收集批注，发送到订货人)，这对于大多数用户来说是最好的包在网关中(对于那些需要它们的人来说，有低级别的API可用)。

但是，我们确实为那些希望为订购者和渠道管理创建自定义工具的人提供了一个Go中的Fabric Config API。