在上周的周记结尾处，曾经说过这周要介绍Fabric的开发和应用。按照原来的写作计划，我打算讲两种开发模式：直接使用FabricAPI和使用Composer框架。但是看完Composer的文档后，我立马取消了原先的计划，直接引入了Composer。选择工具A而不是工具B的原因通常很简单：它易于使用。以我个人为例，在阅读了Fabric的文档后，虽然对Fabric的架构和组件有了清晰的认识，但是对于如何开发它还是很模糊。为什么？原因有二：文档本身给出的开发范式（fabric-samples）缺乏系统的介绍。所谓系统化，说白了，就是对教材性质的介绍，从一个简单的例子开始，逐层推进，最后让读者完全掌握。就目前的文档而言，这个任务显然没有完成。缺乏重点，正如这个Composer幻灯片（第4页）所示，需要担心的事情太多，而真正需要关心的事情（业务逻辑）没有突出显示。Composer正好很好的弥补了Fabric文档中的这两个缺陷。从它的文档构成可以很明显的看出：对Composer进行了全面的介绍，并教你如何完成安装。给出一个HelloWorld级别的示例，说明如何执行一个单元。这种测试如何部署到真实Fabric环境的方法是我最喜欢的。对于开发者来说，他可以快速建立整体印象，建立信心。当然，好的文档不足以让开发人员成为粉丝。使其成为开发首选的原因只有一个：它对开发人员友好。Composer的开发者友好性表现在以下几个方面。1.一个好的抽象的Chaincode是Fabric开发的核心，但是看完例子，说实话，开发者很容易打退堂鼓。因为级别太低了！让人有种回到用Servlet开发JavaWeb应用的感觉。Composer在这一点上做得很好，它的runtime内置了通用的Chaincode。用它来开发完全感觉不到Chaincode的存在。而且整个过程和你开发一个普通的CRUDweb应用程序几乎是一样的！从开发者的角度来看，他是在编写普通的JavaScript函数。本文给出了两种方式（Chaincode和Composer）的开发示例，并在最后提到了两者的代码行差异：这个±10x的代码行数缩减在Go和Composer方案对比时是相当一致的在几个样本中。2.统一的工程经验实际开发并不是书上简单的例子，涉及的人很多。没有好的开发规范，就很难产生好的结果。从Fabric文档中，你看不到一个区块链应用的项目工程应该是什么样子，只能看到零散的代码文件。显然不能满足工程要求。就一个Fabric区块链项目而言，包括：存储在账本上的资产操作Asset的Chaincode访问Chaincode的ClientApp应用相关权限和成员Composer给出了完美的解决方案，将整个开发过程分为3个部分，每个部分都有对应命令行工具，提供统一的开发体验：业务网络，业务逻辑，包括以下组件：资产模型，存储在账本上的资产，过程无异于设计一张数据库表。交易功能对应着Chaincode中的每一个方法，但是对开发者来说是完全透明的。acl文件，权限定义。query，命名查询，供交易函数调用。RestServer将发布到Fabric的业务网络作为RestfulAPI公开，以供外部调用，完全与语言无关。严格来说，对于ClientApp来说，这一步是不需要的，因为上面已经有了语言中立的API，理论上任何框架都可以开发出对应的ClientAPP。但是Composer提供了一个基于Angular的模板来帮助加快这个过程。怎么样，这个过程是不是很熟悉？开发框架固化的开发流程，让开发者更快上手，统一在同一个“大图”下。而且，上述组件对于有经验的开发者来说并不陌生，有助于快速理解。你可以在文档中看到这个例子的完整过程。3.内置测试支持即使开发水平很差，他还是希望在交出之前验证自己写的东西。但是，对于Fabric应用来说，这并不是一件容易的事，因为部署过于繁琐。Composer再次拯救开发！Composer内置的运行时为测试提供了很好的支持。由于良好的抽象，这个运行时可以是实际的Fabric或内置的Node.js进程。后者用于测试。更妙的是，这一切对开发者来说是完全透明的，开发出来的上层代码根本不需要改动。对于上进心比较强，想实现自动化测试的同学，这里有一个例子可以参考。4.便捷的CLI工具Composer提供了便捷的CLI，相对于Fabric碎片化的命令集，统一开发、管理和运行任务。开发者可以利用其便捷的实现方式：应用打包部署应用脚手架生成环境管理让开发更专注于手头的任务，而不是将过多的精力分散到准备工作上。说了这么多Composer的好处，再来说说Composer的局限性。就目前的文档而言，我没有看到如何使用它来开发SystemChaincode的示例。另外，我怀疑当前版本不支持它。因此，如果你想开发SystemChaincode，Composer可能不能满足你的需求。而且这个任务不应该被认为是一个批量任务。您可能想知道为什么我没有展示一个实际示例来证明我正在谈论的好处。这只能归咎于Composer的文档写得很好，基本上是傻瓜教程。按照它的步骤，基本不会出问题。如果是这样，为什么要花时间在这上面？毕竟本文的目的只有一个：使用Composer开发未来的Fabric应用，别自虐了！同时，最新一期的ThoughtworksRadar也将其列为“TRIAL”，并给出了如下评价：...然而，chaincode的编程抽象程度相对较低，因为它直接操作账本的状态。此外，在编写第一行区块链代码之前设置基础设施总是需要花费大量时间。建立在Fabric之上的HyperledgerComposer加速了将想法转化为软件的过程。Composer提供DSL来建模业务资产、定义访问控制和构建业务网络。通过使用Composer，您可以通过浏览器快速验证您的想法，而无需设置任何基础设施。最后，请记住：虽然Composer降低了开发门槛，但还是要记得认真研读Fabric文档！
