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

因此，我一直在尝试使用Hyperledger Fabric Client SDK for Go中的网关包以外的包来查找教程和示例。我只找到了几个旧的；在1.4之前。此外，Hyperledger结构文档完全关注网关模型

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

---

最近是否有一个共同的共识，即完全在CLI上执行管理任务（创建通道、加入对等方和部署链码），并将带有网关模型的SDK专用于链码交互？

我们发现有许多人使用“坏的”尝试在同一客户端应用程序中混合管理和运行时任务的实践。我们还在所有SDK中重复管理功能，就长期维护而言，它的扩展性并不好

网关模型旨在简化与结构网络的运行时交互。需要大量可重复的“gorp”（收集背书、发送给订购方），对于大多数用户来说，最好将其包装在网关中（对于需要它们的用户，可以使用低级API）

但是，我们确实为那些希望为订购者和渠道管理创建自定义工具的人提供了一个解决方案