大型javascript应用程序架构模式

《大型javascript应用程序架构模式》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、11月中旬在伦敦举行的jQuerySummit顶级大会上有个session讲的是大型JavaScript应用程序架构，看完PPT以后觉得甚是不错，于是整理一下发给大家共勉。PDF版的PPT下载地址：http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture注：在整理的过程中，发现作者有些思想是返来复去地说，所以删减了一部分，如果你的英文良好，请直接阅读英文的PPT。以下是本文的主要章节：1.什么叫“JavaScript大型程序”？

2、2.顾当前的程序架构3.长远考虑4.头脑风暴5.建议的架构  5.1设计模式       5.1.1模块论           5.1.1.1综述           5.1.1.2Module模式           5.1.1.3对象自面量           5.1.1.4CommonJS模块       5.1.2Facade模式       5.1.3Mediator模式   5.2应用到你的架构       5.2.1Facade-核心抽象       5.2.2Mediator-程序核心       5.2.3紧密联合运作起来6.发布Pub/订阅S

3、ub的延伸：自动注册事件7.Q&A8.致谢什么叫“JavaScript大型程序”？在我们开始之前，我们来定义一下什么叫大型JavaScript站点，很多有经验的JS开发高手也都被challenge住了，有人说超过10万行JavaScript代码才算大型，也有人说JavaScript代码要超过1MB大小才算，其实2者都不能算对，因为不能安装代码量的多少来衡量，很多琐碎的JS代码很容易超过10万行的。我对“大”的定义如下，虽然可能不太对，但是应该是比较接近了：我个人认为，大型JavaScript程序应该是非常重要并且融入了很多卓越开发人员努力，对重量级数据进行处理并

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

5、ontrollers   templates   libraries/toolkits   anapplicationcore.你可能还会将程序单独封装成多个modules，或者使用其他的设计模式，这很好，但是如果这些结构完全代表你的架构的话，就可能会有一些潜在的问题，我们来看看几个重要的点：1.你架构里的东西，有多少可以立即拿出来重用？有没有一些单独的module不依赖别的代码？是自包含么？如果我到你们正在使用的代码库上去随即挑选一些模块module代码，然后放在一个新页面，是否能立即就能使用？你可能会说原理通就可以了，我建议你长久打算一下，如果你的公司之前开

6、发很多重要的程序，突然有一天有人说，这个项目里的聊天模块不错，我们拿出来放在另外一个项目里吧，你能直接拿过来不修改代码就能使用么？2.系统里有多少模块module需要依赖其他模块？系统的各个模块是不是都很紧耦合？在我将这个问题作为concern之前，我先解释一下，不是说所有的模块都绝对不能有任何依赖，比如一个细粒度的功能可能是从base功能扩展来的，我的问题和这种情况不一样，我说的是不同功能模块之前的依赖，理论上，所有的不同功能模块都不应该有太多的依赖。3.如果你程序的某一部分出错了，其他部分是否能够依然工作？如果你构建一个和Gmail差不多的程序，你可以发现G

7、mail里很多模块都是动态加载的，比如聊天chat模块，在初始化页面的时候是不加载的，而且就算加载以后出错了，页面的其他部分也能正常使用。4.你的各个模块Module能很简单的进行测试么？你的每一个模块都有可能用在数百万用户的大型站点上，甚至多个站点都使用它，所以你的模块需要能经得住测试，也就是说，不管是在架构内部还是架构外部，都应该能很简单的去测试，包括大部分的断言在不同的环境下都能够通过。长远考虑架构大型程序的时候，最重要的是要有前瞻性，不能只考虑一个月或者一年以后的情况，要考虑更长久的情况下，有什么改变的可能性？开发人员经常将DOM操作的代码和程序绑定得太

8、紧，尽管有时候已经封装单