大型JavaScript应用程序架构模式

11月中旬在伦敦举行的jQuery Summit顶级大会上有个session讲的是大型JavaScript应用程序架构，看完PPT以后觉得甚是不错，于是整理一下发给大家共勉。

PDF版的PPT下载地址：http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture

注：在整理的过程中，发现作者有些思想是返来复去地说，所以删减了一部分，如果你的英文良好，请直接阅读英文的PPT。

以下是本文的主要章节：

1. 什么叫“JavaScript大型程序”？

2. 顾当前的程序架构

3. 长远考虑

4. 头脑风暴

5. 建议的架构

5.1 设计模式

5.1.1 模块论

5.1.1.1 综述

5.1.1.2 Module模式

5.1.1.3 对象自面量

5.1.1.4 CommonJS模块

5.1.2 Facade模式

5.1.3 Mediator模式

5.2 应用到你的架构

5.2.1 Facade - 核心抽象

5.2.2 Mediator - 程序核心

5.2.3 紧密联合运作起来

6. 发布Pub/订阅Sub的延伸：自动注册事件

7. Q & A

8. 致谢

什么叫“JavaScript大型程序”？

在我们开始之前，我们来定义一下什么叫大型JavaScript站点，很多有经验的JS开发高手也都被challenge住了，有人说超过10万行JavaScript代码才算大型，也有人说JavaScript代码要超过1MB大小才算，其实2者都不能算对，因为不能安装代码量的多少来衡量，很多琐碎的JS代码很容易超过10万行的。

我对“大”的定义如下，虽然可能不太对，但是应该是比较接近了：

	我个人认为，大型JavaScript程序应该是非常重要并且融入了很多卓越开发人员努力，对重量级数据进行处理并且展示给浏览器的程序。

回顾当前的程序架构

我不能强调说这个问题有多重要，很多有经验的开发人员经常说：“现有的创意和设计模式在我上一个中型项目上运行得非常好，所以在稍微大型点的程序里再次使用，应该没问题，对吧？”,在一定程序上是没错的，但别忘记了，既然是大型程序，通常就应该有大的Concerns需要分解关注，我简短解释一下要花时间来review当前运行了很久的程序架构。大多数情况下，当前的JavaScript程序架构应该是如下这个样子的（注意，是JS架构，不是大家常说的ASP.NET MVC）：
    custom widgets
    models
    views
    controllers
    templates
    libraries/toolkits
    an application core.

你可能还会将程序单独封装成多个modules，或者使用其他的设计模式，这很好，但是如果这些结构完全代表你的架构的话，就可能会有一些潜在的问题，我们来看看几个重要的点：

1.你架构里的东西，有多少可以立即拿出来重用？
有没有一些单独的module不依赖别的代码？是自包含么？如果我到你们正在使用的代码库上去随即挑选一些模块module代码，然后放在一个新页面，是否能立即就能使用？你可能会说原理通就可以了，我建议你长久打算一下，如果你的公司之前开发很多重要的程序，突然有一天有人说，这个项目里的聊天模块不错，我们拿出来放在另外一个项目里吧，你能直接拿过来不修改代码就能使用么？

2.系统里有多少模块module需要依赖其他模块？
系统的各个模块是不是都很紧耦合？在我将这个问题作为concern之前，我先解释一下，不是说所有的模块都绝对不能有任何依赖，比如一个细粒度的功能可能是从base功能扩展来的，我的问题和这种情况不一样，我说的是不同功能模块之前的依赖，理论上，所有的不同功能模块都不应该有太多的依赖。

3.如果你程序的某一部分出错了，其他部分是否能够依然工作？
如果你构建一个和Gmail差不多的程序，你可以发现Gmail里很多模块都是动态加载的，比如聊天chat模块，在初始化页面的时候是不加载的，而且就算加载以后出错了，页面的其他部分也能正常使用。

4.你的各个模块Module能很简单的进行测试么？
你的每一个模块都有可能用在数百万用户的大型站点上，甚至多个站点都使用它，所以你的模块需要能经得住测试，也就是说，不管是在架构内部还是架构外部，都应该能很简单的去测试，包括大部分的断言在不同的环境下都能够通过。

长远考虑

架构大型程序的时候，最重要的是要有前瞻性，不能只考虑一个月或者一年以后的情况，要考虑更长久的情况下，有什么改变的可能性？开发人员经常将DOM操作的代码和程序绑定得太紧，尽管有时候已经封装单独的逻辑到不同的模块里了，想想一下，长久以后，为什么不是很好。

我的一个同事曾经说过，一个精确的架构可能不适合未来的情景，有时候是正确的，但是当你需要该做的话，你所付出的money那可是相当地多哦。比如，你可能因为某些性能，安全，设计的原因需要在Dojo, jQuery, Zepto, YUI之间需要选择替换，这时候就有问题了，大部分模块都有依赖，需要钱呀，需要时间啊，需要人呀，对不？

对于一些小型站点没事，但是大型站点确实需要提供一个更加灵活的机制，而不去担心各个模块之间的各种问题，这既然节约钱，又能节约时间。

总结一下，现在你能确定你能不重写整个程序就能替换一些类库么？如果不能，那估计我们下面要讲的内容，就比较适合你了。

很多有经验的JavaScript开发者给出了一些关键的notes：

JavaScriptMVC的作者Justin Meyer说：

构建大型程序最大的秘密就是从来不构建大型程序，而是将程序分解成各个小的模块去做，让每个小模块都可测试，可size化，然后集成到程序里。

High-performance JavaScript websites作者Nicholas,Zakas：
"The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don't know everything, you begin to design the system defensively. You identify the key areas that may change, which often is very easy when you put a little bit of time into it. For instance, you should expect that any part of the app that communicates with another system will likely change, so you need to abstract that away." -

一大堆文字问题，太麻烦了，总结一句就是，一切皆可变，所以要抽象。

jQuery Fundamentals作者Rebecca Murphey：
各个模块之间联系的越密切，重用性越小，改变起来困难越大。

以上这些重要观点，是构建架构的核心要素，我们需要时刻铭记。

头脑风暴

我们来头脑风暴一下，我们需要一个松耦合的架构，各模块之间没有依赖，各个模块和程序进行通信，然后中间层接管和处理反馈相应的消息。

例如，我们如果有一个JavaScript构建在线面包店程序，一个模块发出了一个信息可能是“有42个圆面包需要派件”。我们使用不同的layer层来处理模块发来的消息，做到如下：

模块不直接访问程序核心
模块不直接调用或影响其它的模块

这将防止我们因为某个模块出错，而导致所有的模块出错。

另外一个问题是安全，真实的情况是，大多数人都不认为内部安全是个问题，我们自己心里说，程序是我自己构建的，我知道哪些是公开的那些私有的，安全没问题，但你有没有办法去定义哪个模块才能权限访问程序核心？例如，有一个chat聊天模块，我不想让他调用admin模块，或者不想让它调用有DB写权限的模块，因为这之间存在很脆弱，很容易导致XSS攻击。每个模块不应该能做所有的事情，但是当前大多数架构里的JavaScript代码都有这种的问题。提供一个中间层来控制，哪个模块可以访问那个授权的部分，也就是说，该模块最多只能做到我们所授权的那部分。

建议的架构

我们本文的重点来了，这次我们提议的架构使用了我们都很熟知的设计模式：module, facade和mediator。

和传统的模型不一样的是，为了解耦各个模块，我们只让模块发布一些event事件，mediator模式可以负责从这些模块上订阅消息message，然后控制通知的response，facade模式用户限制各模块的权限。

以下是我们要注意讲解的部分：
    1 设计模式
        1.1 模块论
            1.1.1 综述

补充：web前端 , JavaScript ,