58cv网址导航All rights reserved Powered by
copyright &copyright 。非常超级学习网内容来自网络，如有侵犯请联系客服。|Linux/Windows Mono/DotNet
[ Open Source .NET Development/
使用开源工具进行DotNet软件开发]
这篇是我参加QCon北京2014的演讲内容：
企业应用在软件行业中占有很大的比重，而这类软件多数现在也都采用B/S的模式开发，在这个日新月异的时代，它们的前端开发技术找到了什么改进点呢？
B/S企业软件前端开发模式大体上与桌面软件类似，都是偏重量级的，在前端可能会有较多的业务逻辑，这些业务逻辑如何被合理模块化，与界面分离，以便测试，成为这个领域的一个重要挑战。另一方面，由于企业应用的界面相对规整，偏重的是数据存取，没有太多花哨的东西，所以常见的界面控件也是可枚举的，如何让开发界面的工作能更快完成，甚至由不擅长编写代码的业务设计人员来做，与界面原型的工作合二为一，能提高不少开发效率。
在AngularJS等MV*框架出现之后，给这个领域带来一些契机，架构师们能够有机会去重新规划前端的架构，甚至是开发流程，从而让整个软件的生产更为高效。
本文将探讨它给这个领域带来的变化。
企业应用前端的特点
企业应用系统是一种很常见的软件系统，这类系统的特点是面向某个行业，功能较复杂，对界面的要求一般是整齐，不追求花哨。这类系统通常有C/S和B/S两个流派，其中的B/S方式因为部署和集成的便利，使用得较为普遍。
同样是在浏览器中做东西，写企业应用和网站的差别也很明显。企业应用的业务逻辑较重，前端有一定的厚重性，但是对效果并不追求很多，主要是各类控件的使用，表单的存取值等等。
企业应用产品的一些特点如下：
独占模式。
一般用户使用互联网产品，都是片段时间使用，比如购物或者阅读，做完之后就刷新或者关闭浏览器了，而企业应用往往是工作的全部，从早上上班开始打开，到下班才关掉，一天绝大部分工作都在上面完成，比如一个呼叫中心的操作员。
重业务，轻视觉
企业应用对视觉的追求是比较低的，一般不会要求花哨效果，以业务操作的流畅性为第一目标。
界面规整，模式单一
企业应用的界面布局相对有模式可循，可以用很少的场景来穷举，界面横平竖直，比较规整，使用到的控件元素也是可穷举的，基本没有什么特效。
由于企业应用的用户都相对比较专业，在上岗之前需要经过统一培训，而且每个用户使用的频度较高，很多时候他们会用尽量快捷的方式来做操作，比如键盘，这一点在互联网产品中比较少见。所以，有时候大家为了追求好看，把系统原生的select用div来替换，在这种情况下反而增加了用户的麻烦。
我之前所在的行业中，业务逻辑很复杂，前端可能会需要写很多复杂的逻辑，JS代码大部分是在处理逻辑，而不是界面交互。
加载速度的侧重不同
互联网产品往往很重视首屏优化，但是其策略可能与企业应用不同。比如说，3个200k的模块，在网站型产品中可能优化成一个100k加三个150k的模块，但在企业应用中，很可能优化成一个400k加三个50k的模块。为什么会这样呢？因为内容型的网站讲究的优化策略是分摊，如果首次加载太慢，会很影响用户的信心，但企业应用用户的容忍度是较高的，他并不在乎刚打开的时候慢一些，因为打开了之后就要用一天，对于之后每步操作的模块加载速度倒是要求很高。另外，对于内存泄露的处理，也要求得比较高一些。整个这些策略，其实是来源于C/S系统的影响。
浏览器版本相对宽松
很多时候提到企业应用，大家的想法就是低端，IE6，但其实这个的原因是客户只购买软件，运维一般自己做，每年不会有很多持续的投入来改进，所以导致很多老系统不能持续升级。软件厂商其实反倒可以用更激进的策略去升级浏览器，用户对这个的接受度还是比较高的，使用系统的群体也是比互联网用户小很多的，抛弃老旧浏览器的事情也确实可以干，比如我就见过几年前某电信营业系统预装的都是Firefox。
企业应用常见的前端框架
在开发B/S企业应用前端的人群中，有很大一部分群体选择了服务端的组件化方式，比如JSF之类，它的弊端是与异构服务端的第三方系统集成比较麻烦。也有不少人使用Bindows和ExtJS这样的框架，最近的KendoUI也是个不错的选择。
每种类型选一个有代表性的来说说：
HTC 在浏览器端扩展标签
早期有些团队采用的方式，一般会跟XMLHTTP等结合使用，易于使用，界面代码整洁，但已被主流浏览器抛弃。
JSF等 在服务端生成界面
以后端为主的架构师最推崇的方式，受Struts的MVC模型影响很深，弱化了前端，使得前端蜕化为后端的一种附属。
GWT 编译阶段生成界面
写其他语言来生成HTML和JS，一般会依赖于一种前端UI库。这种方式也比较受后端架构师喜欢，因为他们觉得写JS很头疼，宁可写Java。
ExtJS 用JS封装界面组件，干脆就不要HTML了
这是另外一种极端，从Bindows开始，使用纯逻辑代码来描述界面，走着跟Java Swing一样的道路，也有不少人喜欢。但这种方式在没有好用的界面设计器的情况下非常痛苦。
Flex等 脱离HTML体系，另辟蹊径
这条路其实是对Java Applet的一种延续，好处是可以不受HTML体系的制约，独立发展，所以其实这些体系在企业应用领域的成熟度远超HTML体系。
曾经的企业B/S应用几件宝
有一段时间，我们几乎只有IE6，所以那个时候的前端开发人员很快乐，没有兼容的压力。那时候，我们如何构建前端应用呢？
这是最好用的声明控件的方式。
尽管还没有AJAX的概念，但我们已经可以用它做前后端分离的传输机制了。
在IE里面画矢量图，不使用插件，有其他选择吗？
把XML数据转换成HTML，跟现在的前端模板像吗？
创建右键菜单最好的方式。
单页应用和前端分层
当时这些系统的构建方式也可以算单页应用，我们用iframe来集成菜单，每个菜单有自己独立的功能，整个主界面是始终不会刷新的。
时光飞逝，这些年，前端有了什么本质的改变，产生了翻天覆地的变化吗？
有时候我们回顾一下，却发现多数都是在增加完善一些细节，真正有颠覆性的有比如以RequireJS和SeaJS为代表的模块定义和加载库，npm这样的包管理器，grunt，gulp，百度fis这样的集成开发模式。为什么它们算是本质改进呢？
因为这些标志着前端开发从粗放的模式，逐渐变化到精确控制的形态。比如我们再也不能不管代码的依赖关系，也不能一打开界面就不分青红皂白把所有可能要用到的代码都立刻加载过来，那个时代已经过去了，从任何角度讲，现代的前端开发都在精细化，从代码的可控，到界面体验的精细优化，到整个团队甚至公司甚至互联网上的组件共享，以及前端团队协作流程的改进，这已经是一个很成规模的产业了。
我们把眼光放到2013年，在这一年里最火的前端技术莫过于NodeJS和AngularJS，前者给我们带来的是一种开发方式的改变，后者是一种典型的前端分层方案。Angular是前端MV*框架的一个流派，用过的人都会觉得很爽。它爽在什么地方呢？因为它帮我们做的事情太多了，一个双向绑定，无所不包，凡是存取值相关的操作，基本都不用自己写代码。在企业应用前端功能里，表单的存取值和校验占据了很大的比例，这些事都不用干了，那简直太好了。
如果就因为这个用Angular，那还有些早。有一些第三方代码被称为库，另外一些称为框架，Angular是框架而不是库。框架的含义是，有更强的约束性，并非作为辅助功能来提供的。
先看一下企业应用的通常形态吧，会有一个可配置的菜单，然后多半会采用MDI的形式，能打开多个业务功能，用选项卡的形式展示起来，可以随时切换操作。每个人每天常用的功能是可以穷举的，他进入系统之后，一般要用到下班才关掉。所以这种系统非常适合做成单页应用，开始的时候加载一个总体框架，每点击一个菜单，就加载这个菜单对应的功能模块，放在一个新的选项卡或者别的什么地方展示出来。
在早期做这种系统的时候，一般都会用iframe来集成菜单，这种方式很方便，但是每个菜单页都要载入共同的框架文件，初始化一个环境，数据之间也不能精确共用。
所以现在我们做企业信息系统，不再适合用iframe来集成菜单，所有菜单的业务代码，会在同一个页面的作用域中共存。这在某些方面是便利，比如数据的共享，一个选择全国城市的下拉框，在多个功能中都存在，意味着这些城市的数据我们可以只加载一次。但从另外一个角度来说，也是一种挑战，因为数据之间产生干扰的可能性大大增加了。
我们回顾一下在传统的客户端开发中是怎么做的，早在经典的《设计模式》一书中，就提到了MVC模式，这是一种典型的分层模式。长期以来，在Web开发人员心中的MVC，指的都是Struts框架的那张图，但我们单页应用中的MVC，其实更接近最原始的《设计模式》书中概念。所以我们要在前端分层，而不仅仅把整个前端都推到视图层。
做单页应用，前端不分层是很难办的，当规模扩大的时候，很难处理其中一些隐患。分层更重要的好处是能够从全盘考虑一些东西，比如说数据的共享。跨模块的数据共享是一个比较复杂的话题，搞得不好就会导致不一致的情况，如果考虑到在分层的情况下，把各种数据来源都统一维护，就好办多了。
所以，以AngularJS为代表的前端MV*框架最重要的工作就是做了这些对于分层的指导和约束性工作，在此基础上，我们可以进一步优化单页应用这类产品。
前端的自定义标签体系
构建一个大型企业应用，最重要的是建立整套组件体系。一般针对某行业的软件，长期下来都会有很多固定的模式，可以提炼成组件和规则，从前端来看，体现为控件库和前端逻辑。控件库这个是老生常谈，在很多框架里都有这个概念，但各自对应的机制是不同的。
从写一个界面的角度来讲，最为便利的方式是基于标签的声明式代码，比如我们常见的HTML，还有微软的XAML，Flex中的MXML等，都很直接，设想一下在没有可视化IDE的情况用类似Java Swing和微软WinForm这样的方式编写界面，毫无疑问写XML的方式更易被接受。所以，我们可以得出初步的结论，界面的部分应该写标签。
很遗憾，HTML自带的标签是不足的，它有基本表单输入控件，但是缺乏DataGrid，Tree之类更富有表现性的控件。所以绝大多数界面库，都采用某种使用JavaScript的方式来编写这类控件，比如：
&div id=&tabs&&
&li&&a href=&#tabs-1&&Nunc tincidunt&/a&&/li&
&li&&a href=&#tabs-2&&Proin dolor&/a&&/li&
&li&&a href=&#tabs-3&&Aenean lacinia&/a&&/li&
&div id=&tabs-1&&
&div id=&tabs-2&&
&div id=&tabs-3&&
$(function() {
$( &#tabs& ).tabs();
如果这样，这些复杂控件就都要通过JavaScript来创建和渲染了，这与我们刚才提到的原则是违背的。那我们寻找的是什么呢，是一种能扩展已有HTML体系的东西。在早期，IE浏览器中有HTC，可以通过引入命名空间来声明组件，现在的标准浏览器中又引入了Web Components，在Polymer这个框架中可以看到更多的细节。说到底，这类方式要做些什么事情呢？
隔离组件的实现，让使用变得简单
支持自行扩展新的组件
作一些作用域上的隔离，比如Web Components里面，style标签上可以加作用域，表示这个样式只生效于组件内部
从另外一个角度讲，为什么我们非要这么做不可？最大好处来自哪里？对于大型项目而言，管理成本和变更成本都是需要认真考虑的。如果一个组件，需要在DOM中声明一个节点， 然后再用一个js去获取DOM，把DOM渲染出来，再填充数据的话，这个过程的管理成本是很大的，因为HTML和JS这两个部分丢了一个都会有问题，无论在什么时候，维护一个文件总是比维护多个文件要强的，我们看HTC那种方式，为什么它的使用成本很低，因为它可以把控件自身的DOM、逻辑、样式全部写在自己内部，整个一个文件被人引用就可以了。在现在这个阶段不存在这么好用的技术了，只能退而求其次。
所以，在这个点上，Angular带来的好处是可扩展的标签体系，这也就是标签的语义化。Angular的主打功能之一是指令，使用这种方式，可以很容易扩展标签或者属性。比如，业务开发人员可以直接写：
&tree data=&{{data}}&&&/tree&
这样多么直观，而且可以跟原有的HTML代码一起编写，不造成任何负担。语义化的标签是快速编写界面的不二法门。
有了语义化标签之后，如果我们只写界面不写逻辑，那也够了，但现实往往没有这么美好，我们还要来考虑一下业务逻辑怎么办。
企业应用一般都是面向某行业的，在这个行业内部，会有一些约定俗成的业务模型和流程，这些东西如何复用，一直是一个难题。以往的做法，会把这些东西都放在服务端，用类似Java这样的语言来实现业务元素、业务规则和业务流程的管理。
这种做法所带来的一个缺点就是对界面层的忽视，因为他只把界面层当作展示，对其中可能出现的大量JavaScript逻辑感到无所适从。很多从事这一领域的架构师不认同界面层的厚度，他们认为这一层只应当是很薄的，纯展示相关的，但在这个时代，已经不存在真正轻量级的界面了。
前面提到，我们在前端作分层，把展现层跟业务逻辑层完全隔离，带来的好处就是逻辑层不存在对DOM的操作，只有纯粹的逻辑和远程调用，这么一来，这一层的东西都可以很容易做测试。对于一个大型产品来说，持续集成是很有必要的，自动化测试是持续集成中不可缺少的一环。如果不做分层，这个测试可能就比较难做，现在我们能把容易的先做掉，而且纯逻辑的代码，还可以用更快的方式来测试。
之前我们做前端的单元测试，都需要把代码加载到浏览器来执行，或者自行封装一些“无头浏览器”，也就是不打开实际的展示，模拟这个测试过程。这个过程相对来说还是有些慢，因为它还有加载的这个网络传输的过程，如果我们能在服务端做这个事情呢？
我们看到，最近很火的NodeJS，它从很多方面给了前端工程师一个机会，去更多地把控整个开发流程，在我们这个场景下，如果能把针对前端逻辑的单元测试都放在node里做，那效率就会更高。
二次开发平台
我们来看看，有了这么一套分层机制，又有了界面标签库之后，该做些什么呢？
做企业软件的公司，有不少会做二次开发平台，这个平台的目标是整合一些已有的行业组件，让业务开发人员甚至是不懂技术的业务人员通过简单的拖拉、配置的形式，组合生成新的业务功能。
从界面的角度看，拖拽生成很容易，很多界面原型工具都可以做，但要如何整合数据和业务？因为你要生成的这个功能，是实实在在要拿去用，不是有个样子看就可以，所以要能跟真实数据结合起来。 但这事情谈何容易！
就比如说，界面上有一个选择所属行业的下拉框，里面数据是配置出来的，对这个数据的查询操作在后端，作为一个查询服务或者是业务对象管理起来，有些传统的方式可能是在后端作这个关联，Angular框架可以把这个事情推到前端来。相比Backbone这样的框架来说，Angular由于有双向绑定，这个过程会变得特别省事。一个界面片段想要和数据关联起来，要做的事情就是各种属性的设置，所以动态加载和动态绑定都会比较容易。
partial.html
&li ng-repeat=&item in items&&{{item.name}}&/li&
&div ng-include=&'partial.html'& ng-controller=&CtrlA&&&/div&
function CtrlA($scope) {
$scope.items = [{name:&Tom&}, {name:&Jerry&}];
function CtrlB($scope) {
$scope.items = [{name:&Donald&}, {name:&Micky&}];
在上面的例子里，这个列表显示什么，完全取决于ng-controller=&CtrlA&这句，如果我们把这句搞成配置的，就很容易把数据源换成另外一个CtrlB，甚至说，即使在同一版本上做项目化，引入另外一个包含CtrlA其他版本的js文件，也基本无需更改其他代码，这就达到了二次开发的一个目的：尽可能以配置而不是编码去新增、维护新功能。
现在的企业软件已经不能只考虑PC的浏览器了，很多客户都会有移动办公的需求。响应式设计是一种常见的解决方案，但是在企业应用领域，想要把复杂的业务功能设计成响应式界面的代价太大了，况且界面设计本身就是开发企业软件的这些公司的短板，所以我们的比较简单的办法是对PC和移动终端单独设计界面，这样就有了一个问题了，这两种界面的业务逻辑并没有差别，如果我们要维护两套代码，代价是非常大的，能有什么办法共用一些东西呢？
如果不采用分层的形式，那这个很麻烦，我们注意到两种系统的差异只在UI层，如果我们用分层的模式，可以共用UI层以外的东西。具体到Angular里面来说，比如service，factory，甚至controller都是可以共用的，只有directive和HTML模板随设备产生差异就可以了。
之前我们很少看到有基于Angular的移动端开发框架，但现在有了，比如Ionic，使用这样的框架，可以直接引用已有的业务逻辑代码，只在展示上作一些调整。这么做有很多好处，同时也对代码的架构水准有一定要求，需要把业务逻辑跟界面展示完全切割开。
这样带来的好处也是很明显的，独立的业务逻辑，因为它不依赖于界面了，所以很容易控制，做单元测试，集成测试，打桩等等，总之它是纯逻辑的东西，在后端可以用什么方式保证代码质量，在前端的业务逻辑也一样可以用，业务逻辑可以因此而清晰稳定。
对于企业应用而言，这么做可以极大程度地复用以往的业务逻辑，只在负责最终展示的代码部分作差异化。
上面这些技术性的问题都解决了，剩下的都是规模带来的边际效应，这需要我们从工程化角度去考虑很多问题：
某个JS模块被修改，如何得知会影响谁？
某个界面片段被调整，会影响什么界面？
如何最小化发布？
如何一键测试、打包、压缩？
。。。。。。
这些话题，篇幅所限，不在本文中叙述，可以查看我另外的关于Web应用组件化的文章。
原文地址：
阅读(...) 评论()扫一扫下载手机客户端
扫描我，关注团购信息，享更多优惠
||网络安全
| | | | | | | | | | | | | | | |
||电子电工
汽车交通| | | | | | | | | |
||投资理财
| | | | | | | | | | | | | | | | |
| | | | | | |
| | | | | | | | | | | | | | | | | | |
| | | | | | |||
||外语考试
| | | | | | | | |
| 视频教程|
AngularJS权威教程
“百科全书”式著作，公认的AngularJS经典
定价：￥99.00
校园优惠价：￥74.25 (75折)
促销活动：
商品已成功飞到您的手机啦！快登录手机站看看吧！
下载客户端
> 微信关注“互动出版网”，便捷查询订单，更多惊喜天天有
ISBN：4上架时间：出版日期：2014 年8月开本：16开版次：1-1
所属分类：
　 AngularJS是Google开发的下一代产业级Web应用框架，最早发布于2009年。随着全球众多Web项目（包括SPA，即单页应用）的竞相采用，AngularJS进入了成熟稳定期，是学习和研究下一代Web开发的首选框架。
说到学习AngularJS，相信你早已厌倦了上网搜索、断续阅读的低效方式。本书堪称AngularJS领域的里程碑式著作，它以相当的篇幅涵盖了关于AngularJS的几乎所有内容，既是一部权威教程，又是一部参考指南。对于没有经验的人，本书平实、通俗的讲解，递进、严密的组织，可以让人毫无压力地登堂入室，迅速领悟新一代Web应用开发的精髓。如果你有相关经验，那本书对AngularJS概念和技术细节的全面剖析，以及引人入胜、切中肯綮的讲解，将帮助你彻底掌握这个框架，在自己职业技术修炼之路上更进一步。
《AngularJS权威教程》是学习AngularJS 的公认经典，内容全面，讲解通俗，适合各层次的学习者。作者拥有丰富的AngularJS 开发和教学经验，也是一位全栈工程师。全书35 章，由浅入深地讲解了AngularJS 的基本概念和基本功能，包括模块、作用域、控制器、表达式、指令、路由、依赖注入等，重要的是书中对每一个概念的讲解都配合了恰如其分的示例和代码，让读者通过动手实践，切身体会到这些概念的含义和价值。本书后半部分深入到AngularJS 应用开发，系统地讨论了服务器通信、事件、架构、动画、本地化、安全、缓存、移动应用等主题。
《AngularJS权威教程》适合各个层次的AngularJS 开发人员学习，无论是出于工作需要，还是好奇心的驱使，只要你想彻底理解AngularJS，本书都会让你满载而归。
Ari Lerner
是一位全栈工程师，拥有多年AngularJS经验，自办并运营AngularJS电子报，在著名硅谷工程师培训学校Hack Reactor担任AngularJS讲师。他的工作涉及软件开发的各个层次，包括基础设施开发、前端应用开发和性能优化。他目前住在旧金山一个阳光明媚的地方，还是FullStack.io创始人。
前端工程师，前端基础技术组leader，曾经负责豌豆荚2.0的前端架构设计和主要开发工作，目前负责Front-end Technical Infrastructure的建设，在工作中有丰富的AngularJS使用经验。新浪微博@赵望野。
2005年至今一直从事企业应用前端架构，对富因特网应用有较深刻的认识，致力于前端的高效开发，研究过Backbone和AngularJS的源码，翻译过讲解AngularJS基本原理的文章，对脏数据检测和基于存取器两种监听方式的差异有深刻认识。
网名basecss，目前就职于腾讯CDC，任前端工程师。喜欢阅读，喜欢前端技术，崇尚开源。工作之余翻译过Grunt和Lesscss相关文档，同时也是Lesscss中文社区贡献者。
《AngularJS权威教程》
第1章　初识AngularJS
1.1　浏览器如何获取网页
1.2　浏览器是什么
1.3　AngularJS是什么
1.3.1　AngularJS有什么不同
1.3.2　许可
第2章　数据绑定和第一个AngularJS Web应用
2.1　AngularJS中的数据绑定
2.2　简单的数据绑定
2.3　数据绑定的最佳实践
第3章　模块
3.1.1　name（字符串）
3.1.2　requires（字符串数组）
第4章　作用域
4.1　视图和$scope的世界
4.2　就是HTML而已
4.3　作用域能做什么
4.4　$scope的生命周期
　　2012年上半年，我所在的公司正在开发一个二次开发平台，它的目标是从数据库开始，能自由、方便地定制业务数据、规则、流程、服务接口，还有展现层。在对展现层的实现部分，我思考了很久，对其中部分技术细节还是缺乏好的思路，于是把眼光转到开源社区，无意中发现了AngularJS这样一个框架，详细考察之后，我认为它在很大程度上满足了我们的需求，继而投入了不小的精力进行研究。
　　在这两年里，我差不多遍历了它的源码，了解了很多细节的实现机制，并且与当时研究得较深的几位朋友，比如的作者严清，资深开发者王宇鹏等进行了交流，获得了很多有益的信息，与此同时，也跟Avalon的作者司徒正美有过一些讨论，对前端MV*有了更深入的认识。后来，团队中的大漠穷秋翻译的《用AngularJS开发下一代Web应用》由电子工业出版社出版。作为国内第一本关于AngularJS的译著，它带动了学习和了解AngularJS框架的浪潮，也因此与朴灵的《深入浅出Node.js》一起，成为前端开发人员拓展思维和技能的两本最受欢迎图书。
　　到了2014年，我离开工作9年的地方，来到新的工作环境――苏宁云商，本来心里权衡过，很可能不再有使用AngularJS的业务场景了，不曾想到入职之后面对的几个项目都属于云产品，正适合使用这类框架，因此又继续了对它的深入研究。
　　在此期间，图灵公司的李松峰老师发布了本书招募译者的消息，我心里一动就联系了他。经过沟通之后，我与另外两名译者，豌豆荚的@赵望野和腾讯的@basecss，合作翻译本书，每人负责1/3的内容。第一次正式翻译图书，我很忐忑，翻译过程中也遇到了一些困难。此前我虽翻译过一些技术文章，其中一篇恰好与AngularJS有关，但翻译图书跟翻译文章的差异很大，有很多东西要考虑一致性和连贯性。
　　本书内容丰富，从零开始向读者讲述AngularJS，首先介绍AngularJS的基本概念，以及在一些场景下的简单应用。接着，本书花很大篇幅讲解AngularJS的周边体系。我们使用这样一个框架，自然需要对前端的架构有一些考虑，包括代码的组织，一些第三方库的选择，甚至还有项目的建立、开发、测试、发布等各环节的综合考虑，这不再是一个简单的编码过程，而是一整套工程化的流程。
　　另外，我们也可能需要为这样一套前端的技术栈选择相应的后端服务，比如，可以使用Node.js自己建立，或者是利用互联网上已有的一些强大平台（比如Amazon等），在这些平台的帮助下，我们的AngularJS应用将如虎添翼，到达新的高度。
　　使用一个框架却不去深入了解它的原理，就会一直流于表面，当面对比较复杂的场景时，就找不到优化方案。因此，本书的后面部分也深入剖析了AngularJS的一些原理和拓展主题，比如国际化、移动开发、调试、性能优化等。
　　无论是零基础的入门级开发者，还是有过一定经验的中高级开发人员，都能从本书中受益。
　　目前，前端MV*框架百花齐放，AngularJS只是其中较流行的一种。这些框架孰优孰劣，其实并无定论，每个框架都会有它的适用场景，都有它优秀的一面，也没有哪个框架能够通吃所有业务场景，如果因为对一个框架的喜爱，而把它引入到不适合的产品中，一定是有害无益。
　　因此，我们希望读者在阅读本书时，能够多思考，愿大家在学习本书过程中都能收获满满。这样的话，作为本书译者的我们也将感同身受，与大家一同分享其中的喜悦和满足感。
　　在本书的出版过程中，除了我们三名译者之外，图灵公司的编辑李静也付出了很大的努力，支付宝的玉伯、51JS版主宝玉、百度的berg提出了不少宝贵意见，对此，一并表示衷心感谢。
　　2014年7月
　　何鹏飞的个人致谢
　　感谢我所在的团队，给我提供非常好的环境，让我能学习成长。
　　感谢我在腾讯的导师@TooBug，让我接触到很多新东西，当然包括这本书所讲述的AngularJS。在翻译的过程中他也为我提供了很多帮助。
　　感谢图灵公司的出版团队，本书的出版离不开他们的努力和帮助。
　　最后，还要感谢没有在这里一一列出的帮助过我的每一个人。
　　赵望野的个人致谢
　　Web技术日新月异，每天早上翻看各种技术博客，都有一种逆水行舟不进则退的危机感，而这两年来前端MV*框架无疑是Web前端开发领域最热门的话题之一。之前已经读过本书英文版，其中涵盖了AngularJS开发的全部细节，示例代码清晰易懂，因此接下了中文版的翻译工作，并迫不及待地推荐给所有想学习AngularJS的朋友。感谢李松峰老师的帮助，感谢图灵出版团队的辛勤工作，感谢在翻译本书过程中给予帮助的所有朋友。
　　似乎每天都有新的JavaScript库或框架发布，对此我多少已经有些麻木了。有能力从众多的库或框架中进行筛选是件好事，但至少在我看来，一个应用程序中如果包含了太多的脚本，对于维护来说却是件坏事。随着应用程序中脚本数量的增加，脚本间会产生依赖关系，所以我一直期待能有那么一到两个脚本，就提供我需要的所有核心功能。
　　当我第一次听说AngularJS时，它就立刻引起了我的注意，因为它只通过一个独立的框架就可以构建动态、交互密集型的客户端应用。通过进一步的研究，我确信这个第一判断是正确的，于是开始迷上了这个框架。AngularJS提供了一系列健壮的功能，以及将代码隔离成模块的方法，这对提高可复用性、可维护性和可测试性都是非常有益的。它的核心功能包括DOM操作、动画、模板、双向数据绑定、路由、历史管理、Ajax和测试，等等。
　　基于一个核心框架进行开发虽然很方便，但是学习它却充满挑战。一开始学习AngularJS时，我迷失在各种不同的主题中，并很快变得有些沮丧，甚至开始怀疑它到底是不是我想要的。服务是什么？它和工厂相比有什么区别？作用域服务是怎么同整个系统融合在一起的？指令是什么，我为什么要使用它？将这些零碎的知识点拼在一起形成大局观是我最初要克服的障碍。如果能有一些简明的参考资料，对于降低学习难度大有裨益。
　　很幸运，你已经有了这样一本优秀的参考资料，就是你手上的这本《AngularJS权威教程》，它将帮助你提升学习效率。本书作者将他掌握的AngularJS知识倾囊相授，并以非常容易理解和学习的方式呈现给大家。如果你想更深入地了解数据绑定、实时模板的工作原理、测试AngularJS应用的流程、服务和工厂的作用以及作用域和控制器如何协同工作等知识，那么这本书就是你所需要的。使用功能强大的AngularJS进行开发是一件非常有趣的事情，本书的示例将帮助你快速掌握这个框架。祝你的AngularJS项目一切顺利！
　　Dan Wahlin，瓦林咨询公司
　　首先，我要感谢一直鼓励我完成这本书的每一个人。那些说写书很容易的人，一定没有亲自写过。
　　我还要亲自感谢Q Kuhns对本书语法方面不厌其烦的修改和支持，感谢Erik Trom耐心地对细节进行修订，以及Nate Murray的清晰思路和乐观精神。
　　非常感谢Hack Reactor 的全体成员在2013年的暑期课程中给了我一个探索如何在正式场合讲授AngularJS的机会。
　　同时也要感谢我在30x500的校友们，Sean Iams、Michael Fairchild、Bradly Green、Misko Hevery和整个AirPair团队。
　　最后，感谢那些对这本书的预览版提供帮助的人。我们从社区获得了非常棒的帮助和支持。特别要感谢以下三位：
　　Philip Westwell
　　Saurabh Agrawal
　　Dougal MacPherson
　　关于本书
　　本书包含了能让你成为AngularJS 高手的解决方案。AngularJS是由Google 开发的先进前端框架，借助它你可以快捷高效地开发富交互应用。
　　本书提供了一系列前沿工具，使你在很短的时间内就可以上手创建令人印象深刻的Web体验。它能帮助你解决棘手的问题，并提供了一些可以立刻投入使用的实用技术。
　　本书涵盖的主题可以帮助你构建专业的Web应用，并能够非常顺利地执行。这些主题包括：
　　与RESTful风格的Web服务交互；
　　创建可复用的自定义组件；
　　“在此之前，我为了学习AngularJS总是在网上搜索阅读别人写的博客，但头脑中始终没法建立一个大局观。这本书内容真的很全很全，而且组织得当，讲解通俗，让我对AngularJS有了全面系统的理解。”
　　“我看过好几本AngularJS图书了，只有本书全面、详尽，循循善诱，通俗易懂，其他任何一本都无法与它比肩。”
　　“ 显然，作者Ari Lerner不仅是一位卓越的软件工程师，而且还是一位天才的老师和作者。他把AngularJS的各种功能讲了一个遍，很多抽象的概念都讲得透彻易懂。”
　　――亚马逊读者评论
系列图书推荐 ￥99.00￥74.25
同类热销商品￥108.00￥81.00
订单处理配送
北京奥维博世图书发行有限公司 china-pub,All Rights Reserved