在上周周记的结尾，我曾经说过本周要介绍Fabric的开发和应用。按照最开始的写作计划，我打算讲讲两种开发模式：直接使用Fabric API和利用Composer框架。可在通读完Composer的文档之后，我立即取消了原定计划，直接介绍Composer。
选择工具A而不是B一般情况下理由都很直接：简单易上手。以我个人为例，在翻完Fabric的文档之后，虽然对于Fabric的架构和组件了然于胸，但对于如何开发，其实还是很模糊的。
为什么会这样？
有两个原因：
文档本身给出的开发范例（fabric-samples）缺乏一个系统性的介绍。所谓系统性，说白了就是教科书性质的介绍，由一个简单的例子开始，层层递进，最终让读者全盘掌握。就当前的文档来说，这一任务显然没有达到。
缺乏聚焦，正如这篇Composer幻灯片（第四页）介绍的，有太多东西要操心了，对于真正需要关心的东西（业务逻辑）反而没有突出。
Composer恰好非常好的弥补了Fabric文档中这两个缺陷，从其文档构成可以很明显的看出来：
给出Composer的整体性介绍
手把手教会大家如何完成安装
给出一个Hello World级别的例子
如何进行单元测试
如何部署到真实的Fabric环境
这种方式是我最喜欢的，对于开发者来讲，他能很快建立起整体印象，并且树立起信心。
当然，文档好并不足以吸引开发者成为粉丝。让其成为开发首选的理由只有一个：对开发者友好。
Composer的开发者友好性表现在以下几个方面。
1. 良好的抽象
Chaincode是Fabric开发的核心，但看过了例子之后，说真的，很容易让开发者打退堂鼓。因为太底层了！让人有一种回到用Servlet开发Java Web应用的感觉。
Composer在这一点上做得很好，它的Runtime内置了通用的Chaincode。使用它开发根本不会感到Chaincode的存在。而且整个过程几乎跟你开发一个普通的CRUD Web应用无异！在开发者看来，他就是在写普通的JavaScript函数。
这篇文章给出了两种方式（Chaincode和Composer）的开发范例，在结尾处提到两者的代码行差异：
This ±10x reduction in the number of lines of code when Go and Composer solutions are compared is fairly consistent across several samples.
2. 统一的工程化体验
实际的开发不是书上的简单例子，而且涉及多人，如果没有良好的开发规范，很难产生好的结果。从Fabric文档中，你无法看出一个区块链应用的项目工程应该是什么样子，只能看到一个个零散的代码文件。显然无法满足工程上的要求。
就一个Fabric区块链项目来讲，它包含：
存储于账本上的Asset
操作Asset的Chaincode
访问Chaincode的Client App
应用相关的权限和成员
Composer非常完美地给出了解决方案，将整个开发过程分成3部分，每一部分都有对应的命令行工具，提供统一的开发体验：
Business Network，业务逻辑，其中包括以下组件：
asset model，存储于账本上的Asset，其过程跟设计数据库的表没什么两样。
transaction function，对应Chaincode中的各个方法，但对于开发者来讲完全透明。
acl文件，权限定义。
query，命名查询，供transaction function调用。
Rest Server
将发布到Fabric的Business Network暴露成Restful API，供外部调用，完全语言中立。
Client App
严格来讲，这一步并非必要，因为既然上面已经有了语言中立的API，理论上可以用任何框架来开发相应的Client APP。但Composer提供了一个基于Angular的模板帮助加速这一过程。
怎么样，这个过程是不是非常眼熟？通过开发框架固化的开发过程可以让开发人员更快的上手，并且统一在相同的“big picture”之下。并且，上述的各个组件对于有经验的开发者并不陌生，有助于快速理解。
大家可以在文档中的这个例子中看到完整的过程。
3. 内建测试的支持
即便是水平再烂的开发，他也希望能验证一下自己写的东西才好意思交出去。然而，对于Fabric应用来讲，这可不是件容易的事情，因为部署太繁琐了。
Composer再次拯救了开发！
Composer内置的runtime为测试提供了良好的支持，由于良好的抽象，这个runtime既可以是实际的Fabric，也可以是一个内置的Node.js进程。而后者则是为测试而生的。更好的是，这一切完全对开发者透明，开发的上层代码完全不需要改动。
对于上进心更强，想要实现自动化测试的同学，这里有一个例子可以参考。
4. 便捷的CLI工具
相比起Fabric零散的命令集合，Composer提供了便捷的CLI，统一了开发、管理和运营任务。开发者可以利用它方便的实现：
应用打包和部署
应用脚手架生成
环境管理
让开发更加聚焦于手头的任务，而不是为了准备工作而分散太多精力。
前面说了Composer的那么多好处，接下来说说Composer的局限性。就目前的文档来看，我没有看到如何用它来开发System Chaincode的例子。而且，我怀疑当前的版本并不支持。因此，假如你像要开发的System Chaincode，Composer可能并不能满足你的需要。而这一任务应该算不上一个大众型任务。
或许你会奇怪，为什么我没有展示一个实际的例子来证明我说的这些好处。这只能怪Composer的文档写得太好了，基本是傻瓜式教程，按照它的步骤，基本不会出现什么问题。既然是这样，干嘛还要花时间在这个上面呢？
说到底，本文的目的只有一个：用Composer来开发未来的Fabric应用，不要再自虐了！同时，最新一期的Thoughtworks雷达也将其列为“TRIAL”并给出了下面的评语：
... However, the programming abstraction of chaincode is relatively low level given it manipulates the state of the ledger directly. Moreover, it always takes a lot of time to set up infrastructure before writing the first line of blockchain code. Hyperledger Composer, which builds on top of Fabric, accelerates the process of turning ideas into software. Composer provides DSLs to model business assets, define access control and build a business network. By using Composer you could quickly validate your idea through a browser without setting up any infrastructure.
最后，请大家记住：即使Composer降低了开发的门槛，但还是要记得认真学习Fabric文档哟！