我使用一个受Ben Nolan的行为启发的自定义脚本(很遗憾，我再也找不到这个脚本的当前链接了)来存储我的大多数事件处理程序。例如，这些事件处理程序由元素className或Id触发。 例子:

Behaviour.register({ 
    'a.delete-post': function(element) {
        element.observe('click', function(event) { ... });
    },

    'a.anotherlink': function(element) {
        element.observe('click', function(event) { ... });
    }

});

我喜欢动态地包含大多数Javascript库，除了那些包含全局行为的库。为此，我使用Zend Framework的headScript()占位符帮助器，但您也可以使用javascript加载其他脚本，例如Ajile。

您没有提到服务器端语言是什么。或者，更确切地说，您在服务器端使用什么框架(如果有的话)。

IME，我在服务器端组织东西，让它全部震动到网页上。该框架的任务不仅是组织每个页面必须加载的JS，还包括与生成的标记一起工作的JS片段。这样的片段通常不希望发出超过一次——这就是为什么它们被抽象到框架中，以便代码处理该问题。: -)

对于必须发出自己的JS的最终页面，我通常发现生成的标记中有一个逻辑结构。这种本地化的JS通常可以在这种结构的开始和/或结束处组装。

请注意，这些都不能免除您编写高效JavaScript的责任!: -)

我认为这可能与DDD(领域驱动设计)有关。我正在开发的应用程序，虽然缺乏正式的API，但确实通过服务器端代码(类/文件名等)给出了提示。有了这些，我创建了一个顶级对象作为整个问题域的容器;然后，我在需要的地方添加名称空间:

var App;
(function()
{
    App = new Domain( 'test' );

    function Domain( id )
    {
        this.id = id;
        this.echo = function echo( s )
        {
            alert( s );
        }
        return this;
    }
})();

// separate file
(function(Domain)
{
    Domain.Console = new Console();

    function Console()
    {
        this.Log = function Log( s )
        {
            console.log( s );
        }
        return this;
    }
})(App);

// implementation
App.Console.Log('foo');

好的OO + MVC原则对于管理一个复杂的javascript应用程序肯定大有帮助。

基本上，我将我的应用程序和javascript组织成以下熟悉的设计(从我的桌面编程到Web 2.0一直存在)

图像上数值的说明:

Widgets representing the views of my application. This should be extensible and separated out neatly resulting good separation that MVC tries to achieve rather than turning my widget into a spaghetti code (equivalent in web app of putting a large block of Javascript directly in HTML). Each widget communicate via others by listening to the event generated by other widgets thus reducing the strong coupling between widgets that could lead to unmanageable code (remember the day of adding onclick everywhere pointing to a global functions in the script tag? Urgh...) Object models representing the data that I want to populate in the widgets and passing back and forth to the server. By encapsulating the data to its model, the application becomes data format agnostics. For example: while Naturally in Javascript these object models are mostly serialized and deserialized into JSON, if somehow the server is using XML for communication, all I need to change is changing the serialization/deserialization layer and not necessarily needs to change all the widget classes. Controller classes that manage the business logic and communication to the server + occasionally caching layer. This layer control the communication protocol to the server and put the necessary data into the object models Classes are wrapped neatly in their corresponding namespaces. I am sure we all know how nasty global namespace could be in Javascript.

In the past, I would separate the files into its own js and use common practice to create OO principles in Javascript. The problem that I soon found that there are multiple ways to write JS OO and it's not necessarily that all team members have the same approach. As the team got larger (in my case more than 15 people), this gets complicated as there is no standard approach for Object Oriented Javascript. At the same time I don't want to write my own framework and repeat some of the work that I am sure smarter people than I have solved.

jQuery是非常好的Javascript框架，我喜欢它，但随着项目越来越大，我显然需要额外的结构为我的web应用程序，特别是促进标准化OO实践。就我自己而言，经过几次试验，我发现YUI3 Base和Widget (http://yuilibrary.com/yui/docs/widget/和http://yuilibrary.com/yui/docs/base/index.html)基础设施完全满足了我的需要。我使用它们的几个原因。

It provides Namespace support. A real need for OO and neat organization of your code It support notion of classes and objects It gives a standardize means to add instance variables to your class It supports class extension neatly It provides constructor and destructor It provides render and event binding It has base widget framework Each widget now able to communicate to each other using standard event based model Most importantly, it gives all the engineers an OO Standard for Javascript development

与许多观点相反，我不一定要在jQuery和YUI3之间做出选择。这两者可以和平共处。虽然YUI3为我复杂的web应用程序提供了必要的OO模板，但jQuery仍然为我的团队提供了我们都喜欢和熟悉的易于使用的JS抽象。

使用YUI3，我成功地创建了MVC模式，通过分离将Base扩展为模型的类，将Widget扩展为视图的类，当然还有进行必要逻辑和服务器端调用的控制器类。

Widget可以使用基于事件的模型相互通信，并根据预定义的接口侦听事件并执行必要的任务。简单地说，把OO + MVC结构的JS是一个乐趣对我来说。

声明一下，我不是为雅虎工作的!仅仅是一个建筑师在试图解决最初的问题所带来的问题。我认为如果有人找到了等效的OO框架，这也可以。基本上，这个问题也适用于其他技术。感谢所有提出OO原则+ MVC的人，使我们的编程更易于管理。

在我的上一个项目- viajeros.com -我使用了几种技术的组合。我不知道如何组织一个网页应用程序——Viajeros是一个面向旅行者的社交网站，它有明确定义的部分，所以很容易将每个部分的代码分开。

我根据站点部分使用名称空间模拟和延迟加载模块。在每个页面加载我声明一个“vjr”对象，并总是加载一组常用函数到它(vjr.base.js)。然后每个HTML页面用简单的语句决定哪些模块需要:

vjr.Required = ["vjr.gallery", "vjr.comments", "vjr.favorites"];

Vjr.base.js从服务器获取并执行每一个gzip文件。

vjr.include(vjr.Required);
vjr.include = function(moduleList) {
  if (!moduleList) return false;
  for (var i = 0; i < moduleList.length; i++) {
    if (moduleList[i]) {
      $.ajax({
        type: "GET", url: vjr.module2fileName(moduleList[i]), dataType: "script"
      });
    }
  }
};

每个“模块”都有这样的结构:

vjr.comments = {}

vjr.comments.submitComment = function() { // do stuff }
vjr.comments.validateComment = function() { // do stuff }

// Handlers
vjr.comments.setUpUI = function() {
    // Assign handlers to screen elements
}

vjr.comments.init = function () {
  // initialize stuff
    vjr.comments.setUpUI();
}

$(document).ready(vjr.comments.init);

鉴于我有限的Javascript知识，我知道一定有更好的方法来管理这个，但到目前为止，它为我们工作得很好。

Dojo从一开始就使用模块系统。事实上，它被认为是Dojo的基石，是将所有Dojo结合在一起的粘合剂:

dojo。要求——官方文件。 理解dojo.declare, dojo。Require和dojo. provider。 引入Dojo。

使用模块Dojo可以实现以下目标:

Namespaces for Dojo code and custom code (dojo.declare()) — do not pollute the global space, coexist with other libraries, and user's non-Dojo-aware code. Loading modules synchronously or asynchronously by name (dojo.require()). Custom builds by analyzing module dependencies to create a single file or a group of interdependent files (so-called layers) to include only what your web application needs. Custom builds can include Dojo modules and customer-supplied modules as well. Transparent CDN-based access to Dojo and user's code. Both AOL and Google carry Dojo in this fashion, but some customers do that for their custom web applications as well.