Hyperledger fabric 不推荐Hyperledger Composer的原因是什么？

Hyperledger Composer是一个加速业务网络应用程序开发过程的平台。为什么不推荐使用它，以及开发BNA的composer的替代方案是什么？

根据IBM的说法，Hyperledger composer存在以下三个问题：

• Composer从一开始就被设计为支持多个区块链平台，不仅仅是Fabric，但这种设计是有成本的。这种设计意味着有两种完全不同的编程模型——Fabric编程模型（链码）和Composer编程模型（业务网络）。这给用户造成了极大的困惑，他们需要在两种编程模型之间做出“选择”，而这两种模型之间几乎没有相似之处。在这种特殊情况下，选择是一件坏事，许多用户选择在初始探索或POC阶段之后不使用“可选”部分

• 这种设计也使得我们更难采用和展示最新的面料特征。例如，我们目前经常遇到的一个问题是“何时可以在Composer中使用Fabric v1.2私有数据功能？”。虽然我们已经采取了一些措施（getNativeAPI）来帮助解决这个问题，但当我们试图保持区块链平台独立的设计时，我们很难跟上Fabric的最新功能并与之保持一致。这意味着用户已经停止使用Composer，转而使用Fabric进行开发，这是可以理解的

• 最后，你们中使用过Composer的人可能会喜欢我们简单易用的API（JavaScript和REST），用于构建与区块链网络交互的应用程序。在幕后有很多代码来启用这些并不真正属于Composer的API。我们最终所做的是美化底层的低级结构API，而不是直接将改进推进到这些结构API中。如今，使用Fabric API提交事务需要约50行代码，而在Composer中需要约5行代码，这是错误的-Composer的价值不应该仅仅来自使Fabric更易于使用

---

详情请阅读

Composer唯一的问题是IBM等人放弃了它。Composer是（某种程度上仍然是）面向潜在客户的Fabric-to-proof-of-concept（POC）业务解决方案的用户的一种有效方式，也是希望证明内部预算合理性以尝试在内部部署项目的用户的一种有效方式。使用真实世界的业务逻辑

Composer应该是位于Fabric之上的业务逻辑堆栈，它允许用户在不必深入研究的情况下进行部署

我不需要知道每个组织都需要一个订购者或CA，但我需要知道我有6个组织将参与我的网络，其中两个组织需要在单独的渠道上使用私有数据进行通信，我需要知道我的业务用例规则是什么。自动化工具或脚本应该允许我在本地启动内部网络**并从那里开始。是的，我需要知道织物的细节，或者手头有人知道，以便能够调整我的网络——但作曲家让我对这些进行POC

Fabric没有类似于zero的功能，事实上，没有任何工具允许用户轻松克隆Fabric样本供自己使用，并轻松插入自己的网络/组织设置

如果你想建立一个内部的、独立的网络而不去IBMCloud，那么IBMVSCodePlugin工具就是垃圾。真正地真的吗

如果没有Composer，或者像它这样的工具，投资Hyperledger结构将是一场巨大的财务和资源赌博和时间消耗。时期代码几乎每周都会更改，存在严重的bug，社区对修复有时会出现的突出文档问题和解决硬件大小问题保持沉默。更不用说指派工程师和软件架构师测试尚不适合黄金时段软件的成本了。忘记仅仅熟悉文档和结构组件以构建业务级网络所需的时间

关于上述答复中提出的几点：

应该有两种不同的编程模型，因为BNA方法从业务部署的角度来看是有效的。如果说在Fabric上有一个Composer堆栈和它的API会“迷惑”用户，就像那句老话“如果客户太笨而不知道如何使用技术性很强的产品，那么客户就太笨了”——这是根本错误的

我不应该每次上车并按下启动按钮时都要更新我对内燃机的知识——我知道我要去哪里，如何到达那里，以及如何操作车辆。如果我想调整或以其他方式修改车辆、发动机、电气系统等，我会拿出相当于织物的文档，学习使用这些工具，或者雇佣一名已经知道如何使用它们的技工

而且设计并没有使采用和公开Fabric的最新特性变得更加困难，开发团队没有做到的是在Composer中实现这些特性，使之与Fabric的发布同步。这是一个开发团队部署问题，而不是最终用户问题。说——不是暗示，是说——社区没有采取行动是一堆废话。如果IBM想要支持它，它可以——它有人力、财力和全球资源来支持它

在现实环境中，企业应用程序的区块链/分布式账本可行性的商业前景并不乐观——事实上，这充其量是值得怀疑的。我们通用电气的第一顺位