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



 写点什么

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：这个项目由哪里领导？