基于WEB技术的网络教学平台_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
您可以上传图片描述问题
联系电话：
请填写真实有效的信息，以便工作人员联系您，我们为您严格保密。
基于WEB技术的网络教学平台
||暂无简介
易发表网提供各学科期刊论文下载、毕业论文...|
总评分0.0|
试读已结束，如果需要继续阅读或下载，敬请购买
定制HR最喜欢的简历
你可能喜欢基于Web Services的数字地图资源发布与检索技术实践--《解放军信息工程大学》2013年硕士论文
基于Web Services的数字地图资源发布与检索技术实践
【摘要】：计算机技术与信息技术的迅猛发展使得传统地图服务的内容和手段发生了巨大的变革，数字资源的网络化改变了传统地图的查询和借阅方式。“地图无处不在”，“地图是我们生活的构成”，传统的地图应用面临着新的挑战，其中一个重要问题是：由于地图内容受限于应用要求，地图数据获取也是一门高深复杂的技术，现有的地图数据都是在分散的环境存储于各自封闭的系统中。空间元数据（即对地图内容和特点的描述）各不相同，这就造成了“信息孤岛”现象。用户检索地图时要耗费很大的时间和精力，而且查准率和查全率不高。Web Services技术以其开放性、封装性、松散耦合等特点为空间元数据库的互连互检提供了一种可行的解决方案。论文将Web Services技术引入到空间元数据的互操作中，提出了便于网络发现的数字地图资源检索模型，设计了原型系统，验证了模型的可行性，为实现空间元数据的发布、共享与互操作提供了一种新的解决方案。论文的主要研究内容和创新点如下：
（1）分析了数字地图资源互连互检的现状，从空间元数据和检索协议入手，探讨了数字地图资源互操作在元数据标准、检索效率和检索协议等方面存在的问题。
（2）研究了空间元数据的定义和标准，研究了《中国可持续发展信息共享元数据标准》，并在此基础上设计了适合于空间元数据互操作的空间元数据概念模型。
（3）研究了Web Services技术的协议规范、体系结构和工作流程，研究了传统异构数据资源统一检索的三种模式，提出了数字地图资源统一检索服务模型，设计了其接口规范、参数格式和关键算法等。
（4）探讨了基于Web Services的数字地图资源检索系统的体系结构，设计了系统架构模型、功能模块和工作流程，完成了一个基于Web Services的数字地图资源发布与检索原型系统。系统总体采用分层架构，层与层间以接口方式通信，各模块之间松散耦合，易于维护和扩展。
【关键词】：
【学位授予单位】：解放军信息工程大学【学位级别】：硕士【学位授予年份】：2013【分类号】：P283.7【目录】：
摘要5-6Abstract6-11第一章 绪论11-18 1.1 研究背景与意义11 1.2 国内外研究现状11-14
1.2.1 国内研究现状11-13
1.2.2 国外研究现状13-14
1.2.3 国内外研究现状总结14 1.3 研究目标和主要研究内容14-15 1.4 论文的研究方法和思路15 1.5 论文组织结构15-17 1.6 本章小结17-18第二章 相关理论与技术研究18-25 2.1 空间元数据研究18-19
2.1.1 元数据的定义18
2.1.2 空间元数据标准18-19 2.2 异构数据源统一检索模型研究19-21
2.2.1 传统检索系统模型19-20
2.2.2 异构数据源统一检索模型20-21 2.3 传统异构数据源统一检索模式分析21-22
2.3.1 中间件模式分析21
2.3.2 元数据整合模式分析21-22
2.3.3 网页搜索代理模式分析22 2.4 Web Services 技术22-24
2.4.1 Web 服务概述22-23
2.4.2 Web 服务的协议23-24
2.4.3 Web 服务的体系结构24 2.5 本章小结24-25第三章 基于 Web Services 的数字地图资源发布与检索系统的架构设计25-33 3.1 Web Services 与数字地图资源发布与检索系统的关系探讨25-26 3.2 基于 Web Services 的数字地图资源检索模式设计26 3.3 基于 Web Services 的数字地图资源发布与检索服务体系26-28 3.4 基于 Web Services 的数字地图资源发布与检索系统的架构设计28-32
3.4.1 系统架构模型设计28-29
3.4.2 系统架构模型分析29-30
3.4.3 系统功能组成分析30-31
3.4.4 系统工作流程分析31-32 3.5 本章小结32-33第四章 基于 Web Services 的数字地图资源发布与检索系统的设计33-54 4.1 系统总体设计33-37
4.1.1 系统设计的基本原则33
4.1.2 系统接口设计33-34
4.1.3 数据库设计34-37 4.2 系统模型设计37-42
4.2.1 数字地图资源统一检索的空间元数据模型设计37-40
4.2.2 数字地图资源统一检索服务模型设计40-42 4.3 系统关键算法研究42-46
4.3.1 数字地图资源统一检索算法研究42-43
4.3.2 数字地图资源统一检索结果融合算法研究43-46
4.3.3 空间元数据更新算法研究46 4.4 系统功能模块设计46-53
4.4.1 用户管理模块设计48-49
4.4.2 元数据管理模块设计49-50
4.4.3 数字地图资源发布与检索服务模块设计50-53 4.5 本章小结53-54第五章 基于 Web Services 的数字地图资源发布与检索系统的实现54-65 5.1 系统开发环境54 5.2 用户管理模块的实现54-56
5.2.1 用户注册和登录模块54-55
5.2.2 权限审核模块55-56
5.2.3 安全认证模块56 5.3 元数据管理模块的实现56-59
5.3.1 元数据导入与导出模块56-57
5.3.2 元数据显示模块57-58
5.3.3 元数据查询模块58-59
5.3.4 元数据更新模块59 5.4 数字地图资源发布与检索模块的实现59-64
5.4.1 数字地图资源发布模块59-60
5.4.2 数字地图资源检索服务注册模块60
5.4.3 数字地图资源检索服务请求处理模块60-61
5.4.4 数字地图资源检索服务分发模块61
5.4.5 数字地图资源检索结果融合模块61-62
5.4.6 数字地图资源统一检索模块62-64 5.5 本章小结64-65第六章 总结与展望65-67 6.1 论文所做的主要工作65-66 6.2 存在的不足及有待深入研究的工作66-67致谢67-68参考文献68-71附录71-77作者简历77
欢迎：、、)
支持CAJ、PDF文件格式
【共引文献】
中国期刊全文数据库
徐振宇;[J];安徽地质;2002年02期
罗英伟,汪小林,许卓群;[J];北京大学学报(自然科学版);2002年03期
王浒,李琦,承继成;[J];北京大学学报(自然科学版);2004年01期
易辉伟,曹红杰,王艳慧;[J];测绘工程;2002年03期
周新忠;余木良;陶亮;郭朋飞;;[J];测绘科学;2007年02期
王永杰;苗丽;周新忠;;[J];测绘科学;2007年05期
杨世杰,李莉,林桂峰;[J];地理信息世界;2004年04期
唐先明,章晓一,王文娟;[J];地理信息世界;2005年01期
赵俊三,徐涛,傅晓东;[J];地理信息世界;2005年03期
赵仁亮;张北飞;王儒;;[J];地理信息世界;2006年04期
中国重要会议论文全文数据库
宋华伟;周莎;朱岩;王耿峰;;[A];中国地理信息系统协会第四次会员代表大会暨第十一届年会论文集[C];2007年
石耀武;高凤亮;;[A];2002年中国西北部重大工程地质问题论坛论文集[C];2002年
王会娜;聂时贵;刘玫;;[A];'2005数字江苏论坛——电子政务与地理信息技术论文专辑[C];2005年
徐财江;陈和平;陈志荣;;[A];2006年中国土地学会学术年会论文集[C];2006年
李刚;许倩英;刘惠瑾;;[A];城市规划和科学发展——2009中国城市规划年会论文集[C];2009年
刘瑞;温家洪;严丽军;姚东京;张振国;;[A];风险分析和危机反应的创新理论和方法——中国灾害防御协会风险分析专业委员会第五届年会论文集[C];2012年
赵军喜;华一新;张亚军;;[A];第四届“测绘科学前沿技术论坛”论文精选[C];2012年
中国博士学位论文全文数据库
谢蓉;[D];华东师范大学;2011年
李斌;[D];长安大学;2009年
岳利群;[D];解放军信息工程大学;2011年
陈永华;[D];解放军信息工程大学;2000年
吴升;[D];解放军信息工程大学;2001年
谢跟踪;[D];福建师范大学;2003年
沈文君;[D];中国农业大学;2004年
吴金华;[D];武汉大学;2003年
傅明;[D];中南大学;2004年
郑晓阳;[D];华东师范大学;2005年
中国硕士学位论文全文数据库
沙志刚;[D];东华大学;2011年
洪志远;[D];中国测绘科学研究院;2011年
李海燕;[D];长安大学;2011年
曹帅;[D];东华大学;2012年
王占宏;[D];西北大学;2000年
周艳明;[D];北京工业大学;2002年
王鹏;[D];中国人民解放军信息工程大学;2002年
姚洪滨;[D];大连理工大学;2002年
简广林;[D];华北电力大学（北京）;2003年
卢亚辉;[D];中国科学院研究生院（遥感应用研究所）;2003年
【相似文献】
中国期刊全文数据库
魏兴涛,朱才连;[J];微型电脑应用;2000年03期
周鹤;王彦颖;;[J];中国地名;2008年12期
吕红霞;;[J];科技创新导报;2009年01期
王强;邓军;;[J];山西建筑;2010年03期
颜菁;;[J];铁道通信信号;2010年03期
彭清涛;李连营;徐志强;张德鑫;;[J];黑龙江交通科技;2010年03期
吴忠性;张世涛;;[J];地图;1993年02期
梅听岳，陶亦军;[J];岩土工程技术;1995年03期
赵学胜,陈军;[J];测绘科学;2000年01期
宣柱香;[J];测绘学院学报;2001年03期
中国重要会议论文全文数据库
于冬梅;董罗海;张立果;;[A];地图学与GIS学术讨论会论文集[C];2002年
何晶;齐清文;;[A];全国地图学与GIS学术会议论文集[C];2004年
陈友飞;;[A];地图学与GIS学术讨论会论文集[C];2002年
高晓梅;;[A];第五届全国地质制图与GIS学术讨论会论文集[C];2007年
祝国瑞;;[A];西部大开发 科教先行与可持续发展——中国科协2000年学术年会文集[C];2000年
高俊;;[A];纪念中国测绘学会成立四十周年论文集[C];1999年
赖进贵;张春兰;王韦力;;[A];海峡两岸地理学术研讨会暨2001年学术年会论文摘要集[C];2001年
艾廷华;郭宝辰;黄亚峰;;[A];中国地理学会2004年学术年会暨海峡两岸地理学术研讨会论文摘要集[C];2004年
臧文刚;;[A];江苏省测绘学会2007'学术年会论文集[C];2008年
张亮;蒋成环;龙毅;;[A];中国地理学会2004年学术年会暨海峡两岸地理学术研讨会论文摘要集[C];2004年
中国重要报纸全文数据库
魏衍亮;[N];中国知识产权报;2008年
陈秀雅;[N];苏州日报;2010年
周静文;[N];新华日报;2003年
陈红梅;[N];中华建筑报;2009年
吕宁丰;[N];南京日报;2011年
;[N];文汇报;2000年
牛世英;[N];中国国防报;2003年
宋雨;[N];中国国防报;2000年
鲁胜利;[N];中国国防报;2003年
陈典宏　特约通讯员
张碧周;[N];解放军报;2011年
中国博士学位论文全文数据库
夏松竹;[D];哈尔滨工程大学;2010年
高攀;[D];南京航空航天大学;2001年
朱家诚;[D];合肥工业大学;2005年
胡绘斌;[D];国防科学技术大学;2006年
任怡;[D];国防科学技术大学;2005年
刘诏书;[D];武汉理工大学;2007年
张晓斌;[D];上海大学;2008年
吴敏;[D];东华大学;2006年
李海涛;[D];中国海洋大学;2007年
任兴田;[D];北京邮电大学;2006年
中国硕士学位论文全文数据库
刘文兵;[D];解放军信息工程大学;2013年
刘兰翠;[D];北京工业大学;2010年
汪芳琴;[D];南京航空航天大学;2010年
李孙长;[D];安徽大学;2010年
李飞;[D];复旦大学;2010年
赵小盼;[D];成都理工大学;2010年
王迪;[D];东北财经大学;2006年
郑贞其;[D];北京交通大学;2010年
钱茹;[D];复旦大学;2010年
姚云洪;[D];山东大学;2005年
&快捷付款方式
&订购知网充值卡
400-819-9993
《中国学术期刊（光盘版）》电子杂志社有限公司
同方知网数字出版技术股份有限公司
地址：北京清华大学 84-48信箱 大众知识服务
出版物经营许可证 新出发京批字第直0595号
订购热线：400-819-82499
服务热线：010--
在线咨询：
传真：010-
京公网安备75号基于Web的资源共享网站的设计与实现_吴代文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
基于Web的资源共享网站的设计与实现_吴代文
上传于||暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩1页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢966,690 十月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
基于webpack搭建前端工程解决方案探索
基于webpack搭建前端工程解决方案探索
相关厂商内容
相关赞助商
为中小微企业提供！
对于软件&工程化&，个人以为至少应当有如下特点：
有IDE的支持，负责初始化工程、工程结构组织、debug、编译、打包等工作
有固定或者约定的工程结构，规定软件所依赖的不同类别的资源的存放路径甚至代码的写法等
软件依赖的资源可能来自软件开发者，也有可能是第三方，工程化需要集成对资源的获取、打包、发布、版本管理等能力
和其他系统的集成，如CI系统、运维系统、监控系统等
广泛意义上讲，前端也属于软件工程的范畴。
但前端没有Eclipse、Visual Studio等为特定语言量身打造的IDE。因为前端不需要编译，即改即生效，在开发和调试时足够方便，只需要打开个浏览器即可完成，所以前端一般不会扯到&工程&这个概念。
在很长一段时间里，前端很简单，比如下面简单的几行代码就能够成一个可运行前端应用：
&!DOCTYPE html&
但随着webapp的复杂程度不断在增加，前端也在变得很庞大和复杂，按照传统的开发方式会让前端失控：代码庞大难以维护、性能优化难做、开发成本变高。
感谢Node.js，使得JavaScript这门前端的主力语言突破了浏览器环境的限制可以独立运行在OS之上，这让JavaScript拥有了文件IO、网络IO的能力，前端可以根据需要任意定制研发辅助工具。
一时间出现了以Grunt、Gulp为代表的一批前端构建工具，&前端工程&这个概念逐渐被强调和重视。但是由于前端的复杂性和特殊性，前端工程化一直很难做，构建工具有太多局限性。
诚如张云龙所言：
前端是一种特殊的GUI软件，它有两个特殊性：一是前端由三种编程语言组成，二是前端代码在用户端运行时增量安装。
html、css和js的配合才能保证webapp的运行，增量安装是按需加载的需要。开发完成后输出三种以上不同格式的静态资源，静态资源之间有可能存在互相依赖关系，最终构成一个复杂的资源依赖树（甚至网）。
所以，前端工程，最起码需要解决以下问题：
提供开发所需的一整套运行环境，这和IDE作用类似
资源管理，包括资源获取、依赖处理、实时更新、按需加载、公共模块管理等
打通研发链路的各个环节，debug、mock、proxy、test、build、deploy等
其中，资源管理是前端最需要也是最难做的一个环节。
注：个人以为，与前端工程化对应的另一个重要的领域是前端组件化，前者属于工具，解决研发效率问题，后者属于前端生态，解决代码复用的问题，本篇对于后者不做深入。
前端工程化的探索
前端工程化的建设，早前的做法是使用Grunt、Gulp等构建工具。但本质上它们只是一个任务调度器，将功能独立的任务拆解出来，按需组合运行任务。如果要完成前端工程化，这两者配置门槛很高，每一个任务都需要开发者自行使用插件解决，而且对于资源的依赖管理能力太弱。
在国内，百度出品的也是一种不错的工程化工具的选择，fis内部也解决了资源依赖管理的问题。因笔者没有在项目中实践过fis，所以不进行更多的评价。
webpack以一种非常优雅的方式解决了前端资源依赖管理的问题，它在内部已经集成了许多资源依赖处理的细节，但是对于使用者而言只需要做少量的配置，再结合构建工具，很容易搭建一套前端工程解决方案。
基于webpack的前端自动化工具，可以自由组合各种开源技术栈（Koa/Express/其他web框架、webpack、Sass/Less/Stylus、Gulp/Grunt等），没有复杂的资源依赖配置，工程结构也相对简单和灵活。
在此以开发一个多页面型webapp为例，给出上面所提出的问题的解决方案。
前端开发环境搭建
主要目录结构
# webapp根目录
# 开发目录
# sass生成的css资源目录
# webapp图片资源目录
# webapp js&jsx资源目录
- components/
# 标准组件存放目录
# 组件foo的样式
# 组件foo的逻辑
# 组件foo的模板
# 组件foo的入口
# 第三方纯js库
# 根据项目需要任意添加的代码目录
# webapp前端模板资源目录
# webapp入口文件a
# webapp入口文件b
# 编译输出目录，即发布目录
# 编译输出的js目录
# 编译输出的图片目录
# 编译输出的css目录
# 编译输出的入口a
# 编译处理后的入口b
# 假数据目录
# 本地server入口
# 本地路由配置
webpack.config.js
# webpack配置文件
gulpfile.js
# gulp任务配置
package.json
# 项目配置
# 项目说明
这是个经典的前端项目目录结构，项目目结构在一定程度上约定了开发规范。业务开发的同学只需关注src目录即可，开发时尽可能最小化模块粒度，这是异步加载的需要。assets是整个工程的产出，无需关注里边的内容是什么，至于怎么打包和解决资源依赖的，往下看。
本地开发环境
我们使用开源web框架搭建一个webserver，便于本地开发和调试，以及灵活地处理前端路由，以koa为例，主要代码如下：
var http = require('http');
var koa = require('koa');
var serve = require('koa-static');
var app = koa();
var debug = process.env.NODE_ENV !== 'production';
var viewDir = debug ? 'src' : 'assets';
app.use(serve(path.resolve(__dirname, viewDir), {
app = http.createServer(app.callback());
app.listen(3005, '0.0.0.0', function() {
console.log('app listen success.');
运行node app启动本地server，浏览器输入http://localhost:8080/a.html即可看到页面内容，最基本的环境就算搭建完成。
如果只是处理静态资源请求，可以有很多的替代方案，如Fiddler替换文件、本地起Nginx服务器等等。搭建一个Web服务器，它能够非常灵活地配置路由和处理动态请求，可以任意定制开发环境的个性化需求用于提升开发效率，总之local webserver拥有无限的可能。
定制动态请求
我们的local server是localhost域，在ajax请求时为了突破前端同源策略的限制，本地server需支持代理其他域下的api的功能，即proxy。同时还要支持对未完成的api进行mock的功能。
var router = require('koa-router')();
var routes = require('./routes');
routes(router, app);
app.use(router.routes());
// routes.js
var proxy = require('koa-proxy');
var list = require('./mock/list');
module.exports = function(router, app) {
// mock api
// 可以根据需要任意定制接口的返回
router.get('/api/list', function*() {
var query = this.query || {};
var offset = query.offset || 0;
var limit = query.limit || 10;
var diff = limit - list.
if(diff &= 0) {
this.body = {code: 0, data: list.slice(0, limit)};
var arr = list.slice(0, list.length);
var i = 0;
while(diff--) arr.push(arr[i++]);
this.body = {code: 0, data: arr};
// proxy api
router.get('/api/foo/bar', proxy({url: ''}));
webpack资源管理
资源的获取
ECMAScript 6之前，前端的模块化一直没有统一的标准，仅前端包管理系统就有好几个。所以任何一个库实现的loader都不得不去兼容基于多种模块化标准开发的模块。
webpack同时提供了对CommonJS、AMD和ES6模块化标准的支持，对于非前三种标准开发的模块，webpack提供了的功能。
受Node.js的影响，越来越多的前端开发者开始采用CommonJS作为模块开发标准，npm已经逐渐成为前端模块的托管平台，这大大降低了前后端模块复用的难度。
在webpack配置项里，可以把node_modules路径添加到resolve search root列表里边，这样就可以直接load npm模块了：
// webpack.config.js
resolve: {
root: [process.cwd() + '/src', process.cwd() + '/node_modules'],
alias: {},
extensions: ['', '.js', '.css', '.scss', '.ejs', '.png', '.jpg']
&div class="se-preview-section-delimiter">&/div>
$ npm install jquery react --save
&div class="se-preview-section-delimiter">&/div>
// page-x.js
import $ from 'jquery';
import React from 'react';
根据webpack的设计理念，所有资源都是&模块&，webpack内部实现了一套资源加载机制，这与Requirejs、Sea.js、Browserify等实现有所不同，除了借助插件体系加载不同类型的资源文件之外，webpack还对输出结果提供了非常精细的控制能力，开发者只需要根据需要调整参数即可：
// webpack.config.js
// webpack loaders的配置示例
loaders: [
test: /\.(jpe?g|png|gif|svg)$/i,
loaders: [
'image?{bypassOnDebug: true, progressive:true, \
optimizationLevel: 3, pngquant:{quality: "65-80"}}',
'url?limit=10000&name=img/[hash:8].[name].[ext]',
test: /\.(woff|eot|ttf)$/i,
loader: 'url?limit=10000&name=fonts/[hash:8].[name].[ext]'
{test: /\.(tpl|ejs)$/, loader: 'ejs'},
{test: /\.js$/, loader: 'jsx'},
{test: /\.css$/, loader: 'style!css'},
{test: /\.scss$/, loader: 'style!css!scss'},
简单解释下上面的代码，test项表示匹配的资源类型，loader或loaders项表示用来加载这种类型的资源的loader，loader的使用可以参考，更多的loader可以参考。
对于开发者来说，使用loader很简单，最好先配置好特定类型的资源对应的loaders，在业务代码直接使用webpack提供的require（source path）接口即可：
// 加载css资源
require('../css/a.css');
// 加载其他js资源
var foo = require('./widgets/foo');
var bar = require('./widgets/bar');
// 加载图片资源
var loadingImg = require('../img/loading.png');
var img = document.createElement('img');
img.src = loadingI
注意，require()还支持在资源path前面指定loader，即require(![loaders list]![source path])形式：
require("!style!css!less!bootstrap/less/bootstrap.less");
// “bootstrap.less”这个资源会先被"less-loader"处理，
// 其结果又会被"css-loader"处理，接着是"style-loader"
// 可类比pipe操作
require()时指定的loader会覆盖配置文件里对应的loader配置项。
资源依赖处理
通过loader机制，可以不需要做额外的转换即可加载浏览器不直接支持的资源类型，如.scss、.less、.json、.ejs等。
但是对于css、js和图片，采用webpack加载和直接采用标签引用加载，有何不同呢？
运行webpack的打包命令，可以得到a.js的输出的结果：
webpackJsonp([0], {
/***/function(module, exports, __webpack_require__) {
__webpack_require__(6);
var foo = __webpack_require__(25);
var bar = __webpack_require__(26);
var loadingImg = __webpack_require__(24);
var img = document.createElement('img');
img.src = loadingI
/***/function(module, exports, __webpack_require__) {
/***/function(module, exports, __webpack_require__) {
/***/function(module, exports) {
/***/function(module, exports) {
/***/function(module, exports) {
从输出结果可以看到，webpack内部实现了一个全局的webpackJsonp()用于加载处理后的资源，并且webpack把资源进行重新编号，每一个资源成为一个模块，对应一个id，后边是模块的内部实现，而这些操作都是webpack内部处理的，使用者无需关心内部细节甚至输出结果。
上面的输出代码，因篇幅限制删除了其他模块的内部实现细节，完整的输出请看，来看看图片的输出：
/***/function(module, exports) {
module.exports = "data:image/base64,...";
注意到图片资源的loader配置：
test: /\.(jpe?g|png|gif|svg)$/i,
loaders: [
'image?...',
'url?limit=10000&name=img/[hash:8].[name].[ext]',
意思是，图片资源在加载时先压缩，然后当内容size小于~10KB时，会自动转成base64的方式内嵌进去，这样可以减少一个HTTP的请求。当图片大于10KB时，则会在img/下生成压缩后的图片，命名是[hash:8].[name].[ext]的形式。hash:8的意思是取图片内容hushsum值的前8位，这样做能够保证引用的是图片资源的最新修改版本，保证浏览器端能够即时更新。
对于css文件，默认情况下webpack会把css content内嵌到js里边，运行时会使用style标签内联。如果希望将css使用link标签引入，可以使用ExtractTextPlugin插件进行提取。
资源的编译输出
webpack的三个概念：模块（module）、入口文件（entry）、分块（chunk）。
其中，module指各种资源文件，如js、css、图片、svg、scss、less等等，一切资源皆被当做模块。
webpack编译输出的文件包括以下2种：
entry：入口，可以是一个或者多个资源合并而成，由html通过script标签引入
chunk：被entry所依赖的额外的代码块，同样可以包含一个或者多个文件
下面是一段entry和output项的配置示例：
a: './src/js/a.js'
path: path.resolve(debug ? '__build' : './assets/'),
filename: debug ? '[name].js' : 'js/[chunkhash:8].[name].min.js',
chunkFilename: debug ? '[chunkhash:8].chunk.js' : 'js/[chunkhash:8].chunk.min.js',
publicPath: debug ? '/__build/' : ''
其中entry项是入口文件路径映射表，output项是对输出文件路径和名称的配置，占位符如[id]、[chunkhash]、[name]等分别代表编译后的模块id、chunk的hashnum值、chunk名等，可以任意组合决定最终输出的资源格式。hashnum的做法，基本上弱化了版本号的概念，版本迭代的时候chunk是否更新只取决于chnuk的内容是否发生变化。
细心的同学可能会有疑问，entry表示入口文件，需要手动指定，那么chunk到底是什么，chunk是怎么生成的？
在开发webapp时，总会有一些功能是使用过程中才会用到的，出于性能优化的需要，对于这部分资源我们希望做成异步加载，所以这部分的代码一般不用打包到入口文件里边。
对于这一点，webpack提供了非常好的支持，即，即使用require.ensure()作为代码分割的标识。
例如某个需求场景，根据url参数，加载不同的两个UI组件，示例代码如下：
var component = getUrlQuery('component');
if('dialog' === component) {
require.ensure([], function(require) {
var dialog = require('./components/dialog');
// todo ...
if('toast' === component) {
require.ensure([], function(require) {
var toast = require('./components/toast');
// todo ...
url分别输入不同的参数后得到瀑布图：
webpack将require.ensure()包裹的部分单独打包了，即图中看到的[hash].chunk.js，既解决了异步加载的问题，又保证了加载到的是最新的chunk的内容。
假设app还有一个入口页面b.html，那麽就需要相应的再增加一个入口文件b.js，直接在entry项配置即可。多个入口文件之间可能公用一个模块，可以使用CommonsChunkPlugin插件对指定的chunks进行公共模块的提取，下面代码示例演示提取所有入口文件公用的模块，将其独立打包：
var chunks = Object.keys(entries);
plugins: [
new CommonsChunkPlugin({
name: 'vendors', // 将公共模块提取，生成名为`vendors`的chunk
chunks: chunks,
minChunks: chunks.length // 提取所有entry共同依赖的模块
资源的实时更新
引用模块，webpack提供了require() API（也可以通过添加bable插件来支持ES6的import语法）。但是在开发阶段不可能改一次编译一次，webpack提供了强大的热更新支持，即。
HMR简单说就是webpack启动一个本地webserver（webpack-dev-server），负责处理由webpack生成的静态资源请求。注意webpack-dev-server是把所有资源存储在内存的，所以你会发现在本地没有生成对应的chunk访问却正常。
下面这张来自webpack官网的图片，可以很清晰地说明module、entry、chunk三者的关系以及webpack如何实现热更新的：
enter0表示入口文件，chunk1~4分别是提取公共模块所生成的资源块，当模块4和9发生改变时，因为模块4被打包在chunk1中，模块9打包在chunk3中，所以HMR runtime会将变更部分同步到chunk1和chunk3中对应的模块，从而达到hot replace。
webpack-dev-server的启动很简单，配置完成之后可以通过cli启动，然后在页面引入入口文件时添加webpack-dev-server的host即可将HMR集成到已有服务器：
&script src="http://localhost:8080/__build/vendors.js">&/script>
&script src="http://localhost:8080/__build/a.js">&/script>
因为我们的local server就是基于Node.js的webserver，这里可以更进一步，将webpack开发服务器以中间件的形式集成到local webserver，不需要cli方式启动（少开一个cmd tab）：
var webpackDevMiddleware = require('koa-webpack-dev-middleware');
var webpack = require('webpack');
var webpackConf = require('./webpack.config');
app.use(webpackDevMiddleware(webpack(webpackConf), {
contentBase: webpackConf.output.path,
publicPath: webpackConf.output.publicPath,
hot: true,
stats: webpackConf.devServer.stats
启动HMR之后，每次保存都会重新编译生成新的chnuk，通过控制台的log，可以很直观地看到这一过程：
公用代码的处理：封装组件
webpack解决了资源依赖的问题，这使得封装组件变得很容易，例如：
// js/components/component-x.js
require('./component-x.css');
// @see /okonet/ejs-loader
var template = require('./component-x.ejs');
var str = template({foo: 'bar'});
function someMethod() {}
exports.someMethod = someM
// js/a.js
import {someMethod} from "./components/component-x";
someMethod();
正如开头所说，将三种语言、多种资源合并成js来管理，大大降低了维护成本。
对于新开发的组件或library，建议推送到npm仓库进行共享。如果需要支持其他加载方式（如RequireJS或标签直接引入），可以参考webpack提供的项。
资源路径切换
由于入口文件是手动使用script引入的，在webpack编译之后入口文件的名称和路径一般会改变，即开发环境和生产环境引用的路径不同：
// 开发环境
&script src="/__build/vendors.js">&/script>
&script src="/__build/a.js">&/script>
// 生产环境
&script src="/js/460de4b8.vendors.min.js">&/script>
&script src="/js/e7d20340.a.min.js">&/script>
webpack提供了HtmlWebpackPlugin插件来解决这个问题，HtmlWebpackPlugin支持从模板生成html文件，生成的html里边可以正确解决js打包之后的路径、文件名问题，配置示例：
// webpack.config.js
plugins: [
new HtmlWebpackPlugin({
template: './src/a.html',
filename: 'a',
inject: 'body',
chunks: ['vendors', 'a']
这里资源根路径的配置在output项：
// webpack.config.js
publicPath: debug ? '/__build/' : '/'
其他入口html文件采用类似处理方式。
辅助工具集成
local server解决本地开发环境的问题，webpack解决开发和生产环境资源依赖管理的问题。在项目开发中，可能会有许多额外的任务需要完成，比如对于使用compass生成sprites的项目，因目前webpack还不直接支持sprites，所以还需要compass watch，再比如工程的远程部署等，所以需要使用一些构建工具或者脚本的配合，打通研发的链路。
因为每个团队在部署代码、单元测试、自动化测试、发布等方面做法都不同，前端需要遵循公司的标准进行自动化的整合，这部分不深入了。
附上笔者根据本篇的理论所完成的一个前端自动化解决方案项目模板：
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
有些小错误
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。