使用seajs进行模块管理

前端模块化开发的价值

解决命名冲突

我们做项目是常常会做一些通用功能的封装,封装成一个个的函数,然后保存在一个名叫util.js的文件中.这种情况就很有可能在另一个开发人员开发时发生命名冲突.

解决繁琐的文件依赖

基于util.js，我们开始开发UI层通用组件dialog.js,那么我们现在的引用情况应该这样:

假如有更多的依赖关系引用起来就非常的繁琐.

使用Sea.js来解决

seajs是一个模块管理框架,使用seajs需要遵守CMD(Common Module Definition)模块定义规范.一个文件就是一个模块.

通过define函数进行模块定义.

util.js文件的代码如下:

define(function(require,exports){
    exports.each = function(){
        //实现代码
    };
    esxports.log = function(str){
        //实现代码
    }
});

这里的exports向外提供了each和log方法,当这个模块被引用时,可以调用这两个方法.

通过require函数进行模块调用.

dialog.js文件的代码如下:

define(function(require,exports){
    var util = require('./util.js');
    exports.init = function(){
        util.each();
        util.log();
    }
});

这里通过require('./util.js')来调用到util模块.

Sea.js 带来的好处

1. 通过exports暴露接口.这意味着不需要命名空间,也不需要全局变量,解决了命名冲突的问题.

2. 通过require引入依赖.这是一种很好的关注分离，解决了繁琐的文件依赖.

3. 模块的版本管理.通过别名等配置,配合构建工具,可以比较轻松的实现模块的版本管理.

4. 提升可维护性. 模块化可以让每个文件的职责单一,非常利于代码维护.seajs提供nocahce debug等插件,拥有在线调试等功能,能比较明显的提升效率.

5. 前端性恶能优化.seajs通过异步加载模块对页面性能非常有益.seajs提供了combo flush插件，配合服务端,可以很好对页面性能进行调优.

6. 跨环境共享模块.CMD模块定义规范与NOdejs的模块规范非常相近.通过seajs的Nodejs版本,可以很方便实现模块的跨服务器和浏览器共享.

前端的模块化构建可分为两大类。一类是以 Dojo、YUI3、国内的 KISSY 等类库为代表的大教堂模式。在大教堂模式下，所有组件都是颗粒化、模块化的，各组件之间层层分级、环环相扣。另一类是以 jQuery、RequireJS、国内的 Sea.js、OzJS 等类库为基础的集市模式。在集市模式下，所有组件彼此独立、职责单一，各组件通过组合松耦合在一起，协同完成开发.

seajs兼容性

• Chorme 3+

• Firfox 2+

• Safari 3.2+

• Opera 10+

• IE 5.5+

持续更新中。。。