本篇内容介绍了“Web前端中依赖注入的方法是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

专注于为中小企业提供成都做网站、成都网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业秀洲免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了成百上千企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

一、什么是IoC

IoC 的全称叫做 Inversion of Control，可翻译为为「控制反转」或「依赖倒置」，它主要包含了三个准则：

1、高层次的模块不应该依赖于低层次的模块，它们都应该依赖于抽象

2、抽象不应该依赖于具体实现，具体实现应该依赖于抽象

3、面向接口编程 而不要面向实现编程

概念总是抽象的，所以下面将以一个例子来解释上述的概念：

假设需要构建一款应用叫 App，它包含一个路由模块 Router 和一个页面监控模块 Track，一开始可能会这么实现：

// app.js

import Router from './modules/Router';

import Track from './modules/Track';

class App {

constructor(options) {

this.options = options;

this.router = new Router();

this.track = new Track();

this.init();

}

init() {

window.addEventListener('DOMContentLoaded', () => {

this.router.to('home');

this.track.tracking();

this.options.onReady();

});

}

}

// index.js

import App from 'path/to/App';

ew App({

onReady() {

// do something here...

},

});

嗯，看起来没什么问题，但是实际应用中需求是非常多变的，可能需要给路由新增功能(比如实现 history 模式)或者更新配置(启用 history, ew Router({ mode: 'history' }))。这就不得不在 App 内部去修改这两个模块，这是一个 INNER BREAKING 的操作，而对于之前测试通过了的 App 来说，也必须重新测试。

很明显，这不是一个好的应用结构，高层次的模块 App 依赖了两个低层次的模块 Router 和 Track，对低层次模块的修改都会影响高层次的模块 App。那么如何解决这个问题呢，解决方案就是接下来要讲述的 依赖注入(Dependency Injection)。

二、依赖注入

所谓的依赖注入，简单来说就是把高层模块所依赖的模块通过传参的方式把依赖「注入」到模块内部，上面的代码可以通过依赖注入的方式改造成如下方式：

// app.js

class App {

constructor(options) {

this.options = options;

this.router = options.router;

this.track = options.track;

this.init();

}

init() {

window.addEventListener('DOMContentLoaded', () => {

this.router.to('home');

this.track.tracking();

this.options.onReady();

});

}

}

// index.js

import App from 'path/to/App';

import Router from './modules/Router';

import Track from './modules/Track';

ew App({

router: new Router(),

track: new Track(),

onReady() {

// do something here...

},

});

可以看到，通过依赖注入解决了上面所说的 INNER BREAKING 的问题，可以直接在 App 外部对各个模块进行修改而不影响内部。

是不是就万事大吉了?理想很丰满，但现实却是很骨感的，没过两天产品就给你提了一个新需求，给 App 添加一个分享模块 Share。这样的话又回到了上面所提到的 INNER BREAKING 的问题上：你不得不对 App 模块进行修改加上一行 this.share = options.share，这明显不是我们所期望的。

虽然 App 通过依赖注入的方式在一定程度上解耦了与其他几个模块的依赖关系，但是还不够彻底，其中的 this.router 和 this.track 等属性其实都还是对「具体实现」的依赖，明显违背了 IoC 思想的准则，那如何进一步抽象 App 模块呢。

Talk is cheap, show you the code

class App {

static modules = []

constructor(options) {

this.options = options;

this.init();

}

init() {

window.addEventListener('DOMContentLoaded', () => {

this.initModules();

this.options.onReady(this);

});

}

static use(module) {

Array.isArray(module) ? module.map(item => App.use(item)) : App.modules.push(module);

}

initModules() {

App.modules.map(module => module.init && typeof module.init == 'function' && module.init(this));

}

}

经过改造后 App 内已经没有「具体实现」了，看不到任何业务代码了，那么如何使用 App 来管理我们的依赖呢：

// modules/Router.js

import Router from 'path/to/Router';

export default {

init(app) {

app.router = new Router(app.options.router);

app.router.to('home');

}

};

// modules/Track.js

import Track from 'path/to/Track';

export default {

init(app) {

app.track = new Track(app.options.track);

app.track.tracking();

}

};

// index.js

import App from 'path/to/App';

import Router from './modules/Router';

import Track from './modules/Track';

App.use([Router, Track]);

ew App({

router: {

mode: 'history',

},

track: {

// ...

},

onReady(app) {

// app.options ...

},

});

可以发现 App 模块在使用上也非常的方便，通过 App.use() 方法来「注入」依赖，在 ./modules/some-module.js 中按照一定的「约定」去初始化相关配置，比如此时需要新增一个 Share 模块的话，无需到 App 内部去修改内容：

// modules/Share.js

import Share from 'path/to/Share';

export default {

init(app) {

app.share = new Share();

app.setShare = data => app.share.setShare(data);

}

};

// index.js

App.use(Share);

ew App({

// ...

onReady(app) {

app.setShare({

title: 'Hello IoC.',

description: 'description here...',

// some other data here...

});

}

});

直接在 App 外部去 use 这个 Share 模块即可，对模块的注入和配置极为方便。

那么在 App 内部到底做了哪些工作呢，首先从 App.use 方法说起：

class App {

static modules = []

static use(module) {

Array.isArray(module) ? module.map(item => App.use(item)) : App.modules.push(module);

}

}

可以很清楚的发现，App.use 做了一件非常简单的事情，就是把依赖保存在了 App.modules 属性中，等待后续初始化模块的时候被调用。

接下来我们看一下模块初始化方法 this.initModules() 具体做了什么事情：

class App {

initModules() {

App.modules.map(module => module.init && typeof module.init == 'function' && module.init(this));

}

}

可以发现该方法同样做了一件非常简单的事情，就是遍历 App.modules 中所有的模块，判断模块是否包含 init 属性且该属性必须是一个函数，如果判断通过的话，该方法就会去执行模块的 init 方法并把 App 的实例 this 传入其中，以便在模块中引用它。

从这个方法中可以看出，要实现一个可以被 App.use() 的模块，就必须满足两个「约定」：

1. 模块必须包含 init 属性

2. init 必须是一个函数

这其实就是 IoC 思想中对「面向接口编程 而不要面向实现编程」这一准则的很好的体现。App 不关心模块具体实现了什么，只要满足对 接口 init 的「约定」就可以了。

此时回去看 Router 的模块的实现就可以很容易理解为什么要怎么写了：

// modules/Router.js

import Router from 'path/to/Router';

export default {

init(app) {

app.router = new Router(app.options.router);

app.router.to('home');

}

};

“Web前端中依赖注入的方法是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联-成都网站建设公司网站，小编将为大家输出更多高质量的实用文章！

网站栏目：Web前端中依赖注入的方法是什么-创新互联
转载来源：http://chengdu.cdxwcx.cn/article/dihdcp.html