我使用Dojo的包管理(Dojo。Require和dojo. provider)和类系统(dojo.declare，它还允许简单的多重继承)将我所有的类/小部件模块化到单独的文件中。这不仅能让你的代码保持有序，而且还能让你对类/小部件进行惰性/及时加载。

以Jquery为中心的命名空间方式组织您的代码可能看起来如下…并且不会与其他Javascript API(如Prototype, Ext)冲突。

<script src="jquery/1.3.2/jquery.js" type="text/javascript"></script>
<script type="text/javascript">

var AcmeJQ = jQuery.noConflict(true);
var Acme = {fn: function(){}};

(function($){

    Acme.sayHi = function()
    {
        console.log('Hello');
    };

    Acme.sayBye = function()
    {
        console.log('Good Bye');
    };
})(AcmeJQ);

// Usage
//          Acme.sayHi();
// or
// <a href="#" onclick="Acme.sayHi();">Say Hello</a>


</script>

希望这能有所帮助。

我认为这可能与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');

受之前帖子的启发，我制作了一个Rakefile和供应商目录的副本，并与WysiHat (changelog提到的RTE)一起分发，并进行了一些修改，包括使用JSLint进行代码检查和使用YUI Compressor进行缩小。

这个想法是使用Sprockets(来自WysiHat)将多个JavaScripts合并到一个文件中，在发布之前用JSLint检查合并文件的语法，并用YUI Compressor缩小它。

先决条件

Java运行时 红宝石和耙子宝石 您应该知道如何将JAR放入Classpath

现在做的

下载Rhino并将JAR(“js.jar”)放到类路径中 下载YUI Compressor并将JAR (build/yuicompressor-xyz.jar)放到类路径中 下载WysiHat并将“vendor”目录复制到你的JavaScript项目的根目录 下载JSLint for Rhino，并将其放到“vendor”目录中

现在，在JavaScript项目的根目录中创建一个名为“Rakefile”的文件，并向其添加以下内容:

require 'rake'

ROOT            = File.expand_path(File.dirname(__FILE__))
OUTPUT_MERGED   = "final.js"
OUTPUT_MINIFIED = "final.min.js"

task :default => :check

desc "Merges the JavaScript sources."
task :merge do
  require File.join(ROOT, "vendor", "sprockets")

  environment  = Sprockets::Environment.new(".")
  preprocessor = Sprockets::Preprocessor.new(environment)

  %w(main.js).each do |filename|
    pathname = environment.find(filename)
    preprocessor.require(pathname.source_file)
  end

  output = preprocessor.output_file
  File.open(File.join(ROOT, OUTPUT_MERGED), 'w') { |f| f.write(output) }
end

desc "Check the JavaScript source with JSLint."
task :check => [:merge] do
  jslint_path = File.join(ROOT, "vendor", "jslint.js")

  sh 'java', 'org.mozilla.javascript.tools.shell.Main',
    jslint_path, OUTPUT_MERGED
end

desc "Minifies the JavaScript source."
task :minify => [:merge] do
  sh 'java', 'com.yahoo.platform.yui.compressor.Bootstrap', '-v',
    OUTPUT_MERGED, '-o', OUTPUT_MINIFIED
end

如果你正确地完成了所有操作，你应该能够在控制台中使用以下命令:

rake merge——将不同的JavaScript文件合并为一个 Rake检查——检查代码的语法(这是默认任务，因此只需输入Rake) rake minify——准备JS代码的缩小版本

关于源合并

使用Sprockets, JavaScript预处理器可以包括(或要求)其他JavaScript文件。使用以下语法来包含初始文件(名为“main.js”，但你可以在Rakefile中更改)中的其他脚本:

(function() {
//= require "subdir/jsfile.js"
//= require "anotherfile.js"

    // some code that depends on included files
    // note that all included files can be in the same private scope
})();

然后……

看看WysiHat提供的Rakefile来设置自动化单元测试。不错的东西:)

现在揭晓答案

这并没有很好地回答最初的问题。我知道，对此我很抱歉，但我把它贴在这里，因为我希望它能对其他人整理他们的混乱有所帮助。

我解决这个问题的方法是尽可能多地进行面向对象建模，并将实现分离到不同的文件中。那么处理程序应该尽可能短。List singleton的例子也是一个很好的例子。

和名称空间……它们可以被更深层次的物体结构所模仿。

if (typeof org === 'undefined') {
    var org = {};
}

if (!org.hasOwnProperty('example')) {
    org.example = {};
}

org.example.AnotherObject = function () {
    // constructor body
};

我不太喜欢模仿，但是如果您有很多想要移出全局作用域的对象，这可能会很有帮助。

好的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的人，使我们的编程更易于管理。

我尽量避免在HTML中包含任何javascript。所有代码都封装在类中，每个类都在自己的文件中。对于开发，我有单独的<script>标记来包含每个js文件，但是它们被合并到一个更大的包中用于生产，以减少HTTP请求的开销。

通常，我会为每个应用程序创建一个“main”js文件。所以，如果我正在编写一个“调查”应用程序，我将有一个名为“survey.js”的js文件。这将包含进入jQuery代码的入口点。我在实例化期间创建jQuery引用，然后将它们作为参数传递到我的对象中。这意味着javascript类是“纯粹的”，不包含任何对CSS id或类名的引用。

// file: survey.js
$(document).ready(function() {
  var jS = $('#surveycontainer');
  var jB = $('#dimscreencontainer');
  var d = new DimScreen({container: jB});
  var s = new Survey({container: jS, DimScreen: d});
  s.show();
});

我还发现命名约定对于可读性很重要。例如:我在所有jQuery实例前加'j'。

在上面的例子中，有一个类叫做DimScreen。(假设这会使屏幕变暗并弹出一个警告框。)它需要一个div元素，它可以放大以覆盖屏幕，然后添加一个警告框，因此我传入一个jQuery对象。jQuery有一个插件概念，但它似乎有局限性(例如，实例不是持久的，不能访问)，没有真正的好处。因此，DimScreen类将是一个标准的javascript类，只是恰好使用jQuery。

// file: dimscreen.js
function DimScreen(opts) { 
   this.jB = opts.container;
   // ...
}; // need the semi-colon for minimizing!


DimScreen.prototype.draw = function(msg) {
  var me = this;
  me.jB.addClass('fullscreen').append('<div>'+msg+'</div>');
  //...
};

我已经使用这种方法构建了一些相当复杂的应用程序。