了解 Nanoko：JavaScript SOA 平台和构建过程

Nanoko 是由 Ubidreams 和 Dynamis Technologies 开发的一个 JavaScript 构建过程，它被设计用于提供模块化和可重用性来弥补现有工具的不足，而不是做重复发明的工作。

InfoQ 邀请 Ubiderams 的创建者 Romain Pellerin 就该平台进行了一番深入的分析。

InfoQ**：面向大型客户端应用程序的时候，为什么我要选用 Nanoko而不是 ember.js或者 angular.js**呢？

“Nanoko 并不是一个 MVC 或者 MVVM 框架。与 angular 和 ember 不同，Nanoko 提供了一种构建过程以确保构建过程中的可重复性。它还综合了测试、聚合、压缩和一堆 web 语言，比如 Less 和 CoffeeScript。Nanoko 还提供了一个框架来构建和运行模块应用程序。Nanoko 的主要成果来源于这样的组合：工业化的构建过程和模块化的运行时。

Nanoko 并没有将重点放在以 UI 为中心的体系结构上，而是着力于以服务为导向，努力使开发更加灵活，集成更加容易。”

InfoQ：现在有什么产品级应用使用 Nanoko吗？如果有，请举个例子？

“有的，Ubidreams 为 Remy Cointreau 开发了一个叫“Gourmandise”的跨平台应用程序。这个应用程序是一个移动商品目录，是销售部门会见客户时使用的。除了那个 iPad 应用程序外，还有一个 web 应用程序（CMS）也是使用 Nanoko 栈开发的。这个 CMS 可以在任何浏览器上运行（包括 IE8）。

有趣的事实：这两个应用程序的（JavaScript）源代码有 80% 是相同的，只在 UI 上有些差异。之所以会这样是因为它们使用了 Nanoko 提供的架构样式。”

InfoQ**：Nanoko是什么架构的变种？MVC，MVM****，MVVM还是其他的？我查阅了 FAQ，据说 Nanoko**与现有 MV*框架是互补的。

“Nanoko 的定位不是推倒重来。事实上，许多 JavaScript 库正在做惊人的工作。因此，你可以自由选择你的模式和相关的库。然后将它们封装为一个或多个 Nanoko 组件。这些组件之间通过松耦合的方式进行交互，与 web 服务比较接近（不过没有负载）。

Nanoko 简化了体系架构的构建过程。比方说，Ubidreams 曾用的 MVC 模式有如下特征：

• 模型基于服务器返回的 JSON 数据结构而构造。
• 视图是使用 Enyo 和 Twitter Bootstrap 组件实现的。这些组件可用与否取决于设备 / 浏览器的特性。
• 控制器仅仅是 Nanoko 的某种组件（事实上是 h-ubu 式的组件），负责管理模型和视图之间的链接。它也是依赖于服务。
• 服务是可重用的功能（比如安全，网络任务和调度），它也是 Nanoko 的组件并通过控制器来使用。”

InfoQ：如果 Nanoko是补充性的，那么就其本身而言，与其说是一个框架，倒不如看做以离散的模块化的方式来组织你的应用程序的方法，这么说有道理吗？

“是的，这是对 Nanoko 优点很好的评价。与 angular.js 和 backbone.js 这类的框架相比，它更像是一个平台。很明显这种引用取决于你对“框架”的定义。无论如何，将 Nanoko 看做构建基于模块 / 组件应用程序的平台可能更容易一些。”

InfoQ：Nanoko并不是一个框架，这点你同意吗？请解释一下原因。

“我同意这个观点。Nanoko 让你能弥合各种不同的技术。这么做是因为，Nanoko 旨在提升开发的工业化水平和效率。”

InfoQ**：Maven如何与 Nanoko交互？为什么 Maven比 Grunt更好？**

“Maven 是在 Nanoko 工业强度的持续构建 / 交付链的核心。我们对 Maven 或爱或恨。事实上，Maven 已经彻底的改进了 Java 软件构建的方式。我们认为，Maven 的严格性和它的各种规范为 web 开发的工业化铺平了道路。就像 Ant 在几年前为 Java 所做的一样，Grunt 也提供了很大的自由性。然而，没有严格定义的生命周期、强大的依赖项管理和企业产品库，这样的工业化生产就算是不混乱，那也是很艰难的。

使用 Maven 也意味着后端系统和 web 端应用程序也要使用同样的构建系统。这是非常重要的因素。此外，两者的依赖性会变得很简单：只是一个 Maven 依赖。

更不用说发布流程和文档管理也是将 Maven 作为 Nanoko 平台的基石。”

InfoQ**：请解释下 Nanoko和 J2EE应用程序开发如何交互？这个服务器端技术如何与 Nanoko**相互兼容？

“Nanoko 并不是说被绑定到 JavaEE 或者其他后端技术。不过 Nanoko 栈与这些技术相互整合是肯定的。Nanoko 提倡以服务为导向，它的特征都体现在‘服务’上。后台服务器仅仅是提供 RESTful 或者 web 服务。所以在 Nanoko 中实现这些服务就像馅饼一样简单：一个提供了非常相似的服务接口的组件。其他组件仅仅是依赖于这个组件访问服务器的功能罢了。”

InfoQ**：Nanoko与 node.js和 require.js**的区别在哪里？

“首先，Nanoko 与 require.js 和 node.js 是相互兼容的。实际上，它是很推崇它们的。你可以将 Nanoko 看做一种建立和绑定 require 或者 node 的模块的方式。

使用面向服务时，模块的交互是通过预定义的服务完成的（在 Nanoko 中名为合约）。这种松散的耦合允许模块被替换（甚至是在运行的时候）。你能很快地体会到这种模式的益处：根据平台和运行时的上下文选择使用 / 停用各模块、模块的异步开发和相对更方便的检测等等。”

InfoQ：为何你要将 Nanoko开源呢？它将遵循何种协议？

“Nanoko 是多家公司（Ubidreams、dynamis-technologies、Grenoble University 等等）协作努力的结果，这些公司都将开源作为他们的核心价值之一。所以将 Nanoko 的源代码开放对我们来说是很自然的事情。与各位创始人协商后，我们选择可 OW2 联盟，因为我们相当认同 OW2 的价值观。

Nanoko 的源码遵循 Apache License 2.0 协议，在商业应用上没有任何障碍。完全版的代码库可以在 GitHub 上找到。发行版已经公布在 Maven Central 中，因而 Nanoko 的组件使用起来非常方便。”

InfoQ：这个项目由哪里领导？

“领导该项目的机构在法国的拉罗谢尔（Ubidreams HQ）和和格勒诺布尔城（Dynamis technologies HQ）。Nanoko 参加了 OW2 开源联盟来提高国际知名度。在 OW2 和它所有成员的大力支持下，Nanoko 的未来一片光明。”

查看英文原文： Meet Nanoko: a Javascript SOA Platform and Build Process

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。