AngularJS 是 Google 开源出来的一套 js 工具。下面简称其为 ng 。这里只说它是“工具”，没说它是完整的“框架”，是因为它并不是定位于去完成一套框架要做的事。更重要的，是它给我们揭示了一种新的应用组织与开发方式。
ng 最让我称奇的，是它的数据双向绑定。其实想想，我们一直在提数据与表现的分离，但是这里的“双向绑定”从某方面来说，是把数据与表现完全绑定在一起——数 据变化，表现也变化。反之，表现变化了，内在的数据也变化。有过开发经验的人能体会到这种机制对于前端应用来说，是很有必要的，能带来维护上的巨大优势。 当然，这里的绑定与提倡的分离并不是矛盾的。
jQuery主要是用来操作DOM的，如果单单说jQuery的话就是这样一个功能，它的插件也比较多，大家也都各自专注一个功能，可以说jQuery体系是跟着前端页面从静态到动态崛起的一个产物，他的作用就是消除各浏览器的差异，简化和丰富DOM的API，简单易用。
jQuery 是类库，它解决的是特定功能实现，以及跨浏览器解决方案这样的问题；
简单地说，框架帮助你解决“代码如何组织”的问题，类库帮助你解决“如何把代码写得更少/巧/强壮”的问题；它们解决的是不同层面的问题。
对于小型应用来说，因为业务逻辑简单，代码总量不会太大，组织不会是太大得问题，所以用类库就够了；而面对中/大型项目，特别是需要多人共同参与的 项目，选择一个合适的框架有助于写出规范的，易于理解的，易于回复的，低耦合的……等等的代码，在此基础上再使用各种类库来增加具体代码的健壮性与功能性 则更好。
绝不要先设计你的页面，然后用DOM操作去改变它
在jQuery中，你会先设计一个页面，然后让它变得动态化。这是因为jQuery是为了扩展而设计的，并在这个前提下变得越来越臃肿。
但是在Angular.js中， 你必须从一开始就在脑子里挂着架构的弦。不要一开始就想着“我有这样一个DOM，我想让它做X”， 你必须从你要完成的目标开始思考，然后设计你的应用， 最后才是设计你的视图。
根据架构去思考
在jQuery中，我们通过编程方式来改变视图。我们可以像下面这样通过ul标签来定义一个下拉菜单：
<ul class="main-menu">
<li class="active">
<a href="#/home">Home</a>
</li>
<li>
<a href="#/menu1">Menu 1</a>
<ul>
<li><a href="#/sm1">Submenu 1</a></li>
<li><a href="#/sm2">Submenu 2</a></li>
<li><a href="#/sm3">Submenu 3</a></li>
</ul>
</li>
<li>
<a href="#/home">Menu 2</a>
</li>
</ul>
在jQuery中，根据我们应用的逻辑，可以用类似下面的语句来激活它。
$('.main-menu').dropdownMenu();
当我们只是看着视图的时候，不会立刻看出它的功能。对于小应用而言，这样是没问题的。但是对于大型的应用，情况就一下子变得令人困惑并且难以维护。
但是在Angular.js中，视图是基于视图的功能的正式记录。我们的ul是像下面这样声明的：
<ul class="main-menu" dropdown-menu>
...
</ul>
这两者其实做了同样的事情，但是在Angular.js的版本中，任何看到这个模板的人都知道将要发生什么。不论何时，开发团队里有任何新的开发人 员加入，她可以一眼看出有一个叫做dropdownMenu的指令作用在视图上；她根本不需要凭直觉猜测或者研究下代码才找到正确的答案。视图本身就告诉 我们将会发生什么了。清晰多了。
angualrjs的新手经常会问这样一个问题： 我如何找到某一类所有的链接并且给它们添加一个指令呢？当看到我们回复的时候小伙伴都震惊了：压根别去这样做。但是劝你不要这样做的原因是，这样做就像是 一半jQuery，一半angulrjs，而这真心很糟。这里的问题是，开发者想在angualrjs的情境中使用jQuery方式。而这绝对不会玩得 转。视图是正式记录。超出指令的范围（这点下文会谈论更多），你绝不要去改变DOM。而且指令是应用在视图中的，目的自然也一目了然。
记住：不要先设计再修饰。你必须先进行架构，然后再考虑设计。
数据绑定
这是Angular.js目前最酷的特性之一，并且秒杀我前文提到的各种需要的DOM操作。不需要你自己动手，Angular.js将自动更新你的视图有木有!
在jQuery里， 我们响应事件并更新内容，大概是这个样子：
$.ajax({
url: '/myEndpoint.json',
success: function ( data, status ) {
$('ul#log').append('<li>Data Received!</li>');
}
});
视图则看上去是这样的：
<ul class="messages" id="log">
</ul>
除了关注点混合的问题，这里同样有之前提到的表征目的的问题。更重要的是，我们不得不手动引用并更新dom节点。并且如果我们想要删除一个日志，我们不得不再次对dom编程操作。我们怎样才能抛开dom来测试逻辑呢？还有，如果我们希望改变展现呢？
真是让人凌乱。。。
但是在Angular.js中，我们可以这样做：
$http( '/myEndpoint.json' ).then( function ( response ) {
$scope.log.push( { msg: 'Data Received!' } );
});
我们的视图看上去是这样的：
<ul class="messages">
<li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>
但是考虑到刚才提到的问题，我们的视图看上去可以是这样的：
<div class="messages">
<div class="alert" ng-repeat="entry in log">
{{ entry.msg }}
</div>
</div>
现在，替换掉了无序列表，我们使用BootStrap警告框。同时我们根本不需要改变控制器代码！更重要的是，不论日志何时或者如何更新，视图也会跟着改变。自动的！漂亮！
虽然我没有在这里演示出来，但是数据绑定是双向的。所以这些日志信息同样可以在视图中被编辑，就像这样：
<input ng-model="entry.msg" />
是不是更开心了？
不同的模型层
在jQuery中，dom有点像模型。但是在angualrjs中，我们有一个分离的模型层， 而这个模型层可以让我们用任何方式管理，完全独立于视图。这对于上面说的数据绑定很有帮助， 还可以维护关注点分离，并且引入更多的可测试性。其它的答案提到了这点，所以我这里就不再赘述了。
关注点分离
以上所有的这些把我们带入了这样的主题：保持你的关注点分离。你的视图表现的像记录什么会发生（大部分情况）的正式记录；你的模型表现你的数据；你 有一个服务层来执行可重用的任务；你执行dom操作并通过指令扩展你的视图；并且你用控制器来组合这些。这些同样已经在其它答案中提到，我在这里唯一还要 提出的一个事情就是可测试性，我会在下文的另一节里专门讨论。
依赖注入
依赖注入是让我们实现关注点分离的方法。如果你是一个服务器端的开发者（从java到php），你可能对这个概念已经非常熟悉了，但是如果你是一个来自jQuery的客户端的朋友，那么你可能会认为这个概念是傻浅挫。但是它可不是：）
从一个更广的观点来看， 依赖注入意味着你可以非常自由的声明组件，然后你可以通过任意其它组件，呼叫一个它的实例，然后授权。
你不需要知道载入顺序，或者文件位置，或者其它类似的东西。这种强大的力量可能不会立刻显现，但是我这里会提供一个（通常）的例子：测试。
比如在我们的应用中，需要一个通过REST API，同时也依赖于应用状态，本地存储实现了服务器端存储的服务。当在我们的控制器上跑测试的时候，我们不希望与服务器端通讯-毕竟我们在测试控制器。 我们能够仅仅添加一个与我们原始组件同名的mock服务，注入器将确保我们的控制器自动获取伪造对象–我们的控制器不会也不需要知道它们的区别。
原文链接：https://blog.jobbole.com/46589/
不要带着jQuery的思维去学习AngularJS，首发于rainweb前端开发。
转载请注明：TUTERM.COM » 不要带着jQuery的思维去学习AngularJS
