❶ angularjs路由是什么意思
AngularJS路由功能是一个纯前端的解决方案，与我们熟悉的后台路由不太一样。后台路由，通过不同的URL会路由到不同的控制器上 (controller)，再渲染(render)到页面(HTML)。AngularJS的前端路由，需求提前对指定的(ng-app)，定义路由规则 (routeProvider)，然后通过不同的URL，告诉(ng-app)加载哪个页面(HTML)，再渲染到(ng-app)视图(ng- view)中。
AngularJS的前端路由，虽然URL输入不一样，页面展示不一样，其实完成的单页(ng-app)视图(ng-view)的局部刷新。这样来看，AngularJS做单页应用就有点标配的感觉了。
❷ Jquery和Angularjs的区别
1.不要首先设计好你的页面，然后再通过DOM操作去修改它
在jQuery中，你首先设计了一个page，然后再去动态修改它的内容，这是因为jQuery被设计用来进行扩展并在这个前提下大幅度地增加和修改内容，但是在angularjs中，你必须在心中先设计好你的架构，
从一开始，你就要摒弃“我拥有一个DOM元素并且想让它去做某件事”，代之为“需要完成什么任务，然后接着设计你的应用，最后再去设计你的视图view层”。
2.不要使用angularjs去扩展jQuery
相应地，不要存在说让jQuery去干某些事情，然后在此基础上添加angularjs的功能让它去管理model以及controller的想法。所以一般不推荐AngularJS开发新手同时使用jQuery，至少在他们还没有适应AngularJS的开发模式之前不会去推荐这样做，但是当你真正开始适应angularjs 的方式之后，你会发觉这是一件很诱人的事情。
曾经看到过很多开发者采用将150到200行代码的jQuery插件利用angularjs的回调以及$apply方法封装起来，这种方式使得代码看起来极其复杂，但是实际上他们让这些插件跑起来了！问题在于，在大部分情况下jQuery插件能够用angularjs进行重写，并且可能只会使用很少量的代码，同时这种重写使得代码很直观且易于理解，这显然好过于将jQuery代码直接做封装。
所以最后说，当你遇见问题的时候，首先要以angularjs的思维进行思考，如果找不到解决方案，可以求助于社区，如果说没有人能够给出一个简单的方案，那么才考虑使用jQuery，不要让jQuery成为你的拐杖，否则你永远掌握不了AngularJS。
3.要以架构为中心进行思考
首先你要知道单页应用属于web应用，它们不是传统的多网页网站，所以要同时作为一个服务端和客户端开发者的思维进行思考，需要思考如何将我们的应用分为独立的，可扩展的以及可测试的部分。
数据绑定
这是到目前为止AngularJS最令人瞩目的特性了，在数据绑定方面它舍弃了对DOM的操作方式，而这一切都是由AngularJS来自动更新视图，你不必写操作dom的代码，在jQuery中，常常按照响应事件并修改视图
区别model层
在jQuery中，DOM类似于一种model，但是在AngularJS中，拥有不同于jQuery中的model层以便可以以任何我们想要的方式去管理它，它是完全独立于视图之外的。这种方式是有助于进行数据绑定并且可以保持对分离的关注，而且可以具备更好的可测试性。
关注点分离
以上所讲都和这个总体的话题相关：让你关注分离，你的视图层显示记录，你的model层代表数据，你还有个服务层用来执行这些可复用的任务。你使用directive来执行dom操作并扩展你的视图，并将它和controller连接起来，这也就是在其他方面提到的有关于增强可测试性的原因。
依赖注入
帮助解决关注点分离的是依赖注入（DI），如果你是一个服务端开发者（java或者PHP），你可能已经很熟悉这个概念了，但是如果你是从事客户端开发的，你会觉得这个概念可能有些多余和纯属追求时髦，但是实际上不是这样。
从广义的角度讲，DI意味着你可以自由地声明组件然后从这些组件中进行实例化，这是理所当然的。你不必知道加载顺序，文件位置等诸如此类的事情，这种魔力不是能够立即看到，但是会给出一个例子：测试。
说在应用中，需要一个依赖于应用状态和本地存储的服务用来通过一个rest API来执行服务端存储，当我们测试我们的controller时，不必和服务端进行通信，毕竟只是在测试controller而已。仅添加一个与我们最初组件相同的mock服务，注入器能够确保controller获得一个虚拟的服务，controller自身不必也不需要了解这种差异。
4.以测试驱动的开发
这部分是一个架构的第三部分，但是他是很重要的，以至于需要将它放在最重要的位置。
在所有见过的，用过的以及写过的jQuery插件中，有多少具有一套测试组件呢？其实并不多，这是因为jQuery在测试上不易控制，但是AngularJS却与此不同。
在jQuery中，测试的唯一方法是使用一个demo页去创建一个独立组件来使得的测试可以执行dom操作。接下来我们必须开发一个独立的组件然后将它集成到的应用中来，这是多不方便啊！在很多情况下，当使用jQuery开发实际上是做了很多重复开发而不是以测试驱动的开发，
但是在AngularJS中我们可以关注分离点，所以可以做一些测试驱动的开发。
5.从概念上讲，指令不是打包的jQuery
你常常听说，dom操作只能在指令中，这是必须的，你必须严肃对待。
深入讨论，
某些指令仅仅是装饰视图（例如ngClass），因此有时候直接操作dom是可以的，但是当一个指令类似于一个小物件并且拥有自己的模板，那么它应该当做一个分离的关注点，这就是说，它的模板需要和link中的执行逻辑以及其他controller函数分离开。
AngularJS拥有一整套的工具可以是这种分离更简单，使用ngClass指令，可以动态地更新class,使用ngBind可以进行双向数据绑定，使用ngShow和ngHide 我们
可以采用编程的形式显示和隐藏一个元素，也包括自己写的很多指令。换句话说，可以不用Dom操作而完成所有工作，dom操作越少，指令越容易测试，越容易指定他们的style属性，就越容易在将来改变他们，那么他们就越容易复用和分发。
看过很多AngularJS新手使用指令封装一大串 jQuery代码，换句话说，既然不能在controller里面进行dom操作，那么我可以将他放在指令中，虽然这相对于直接操作dom好很多，但是任然是错误的。
看看在上面的记录，即使我们将其放在一个指令中，任然需要以Angular的方式去操作它，这种方式不执行dom操作！在很多时候dom操作是需要的，但是这种情况比你想的要少得多。当需要做dom操作的时候先问问自己这里是否必须这样做，这才是一种更好的方式。
总结
不要总使用jquery ,甚至不要去引用它，它会阻止你前进，当回到这个问题—你知道你怎么在AngularJS中以jquery方式解决问题，但是当你使用诸如$等选择器时，你要想想它们实际上是禁锢了AngularJS，如果你不知道怎么不用jQuery实现，那么去请教别人，一次一次去问，最好的方式是不需要使用jQuery，使用jQuery只会导致你的工作量提升。
❸ 对比jQuery和AngularJS的不同思维模式
jQuery是dom驱动，AngularJS是数据驱动，这里有一篇文章阐述的非常好，建议看看
本文来自StackOverFlow上How do I “think in AngularJS” if I have a jQuery background?一题中得票最高的回答。该回答得票超过3000次，回答者Josh David Miller是活跃于开源社区的开发者，也是Emergenesis公司的联合创始人。该答案最初由数云架构师韩铮翻译并发布在自己的博客上，在征得Josh同意后由韩铮本人推荐给 InfoQ进行分享，并在经过InfoQ社区编辑崔康审校后发布在此。
1. 不要先设计页面，然后再使用DOM操作来改变它的展现
在jQuery中，你通常会设计一个页面，然后再给它动态效果。这是因为jQuery的设计就是为了扩充DOM并在这个简单的前提下疯狂的生长的。
但是在AngularJS里，必须从头开始就在头脑中思考架构。必须从你想要完成的功能开始，然后设计应用程序，最后来设计视图，而非“我有这么一个DOM片段，我想让他可以实现XXX效果”。
2. 不要用AngularJS来加强jQuery
类似的，不要以这样的思维开始：用jQuery来做X，Y和Z，然后只需要把AngularJS的models和controllers加在这上面。这在刚开始的时候显得非常诱人，这也是为什么我总是建议AngularJS的新手完全不使用jQuery，至少不要在习惯使用“Angular Way”开发之前这么做。
我在邮件列表里看到很多开发者使用150或200行代码的jQuery插件创造出这些复杂的解决方案，然后使用一堆callback函数以及$apply把它粘合到AngularJS里，看起来复杂难懂；但是他们最终还是把它搞定了！问题是在大多数情况下这些jQuery插件可以使用很少的AngularJS代码重写，而且所有的一切都很简单直接容易理解。
这里的底线是：当你选择解决方案时，首先“think in AngularJS”；如果想不出一个解决方案，去社区求助；如果还是没有简单的解决方案，再考虑使用jQuery。但是不要让jQuery成为你的拐杖，导致你永远无法真正掌握AngularJS。
3. 总是以架构的角度思考
首先要知道Single-page应用是应用，不是网页。所以我们除了像一个客户端开发者般思考外，还需要像一个服务器端开发者一样思考。我们必须考虑如何把我们的应用分割成独立的，可扩展且可测试的组件。
那么如何做到呢？如何“think in AngularJS”？这里有一些基本原则，对比jQuery。
视图是“Official Record”
在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();
当我们只关注视图，这里不会立即明显的体现出任何（业务）功能。对于小型应用，这没什么不妥。但是在规模较大的应用中，事情就会变得难以理解且难以维护。
而在AngularJS里，视图是基于视图的功能。ul声明就会像这样：
<ul class="main-menu" dropdown-menu> ... </ul>
这两种方式做了同样的东西，但是在AngularJS的版本里任何人看到这个模版都可以知道将会发生什么事。不论何时一个新成员加入开发团队，他看到这个就会知道有一个叫做dropdownMenu的directive作用在这个标签上；他不需要靠直觉去猜测代码的功能或者去看任何代码。视图本身告诉我们会发生什么事。清晰多了。
首次接触AngularJS的开发者通常会问这样一个问题：如何找到所有的某类元素然后给它们加上一个directive。但当我们告诉他：别这么做时，他总会显得非常的惊愕。而不这么做的原因是这是一种半jQuery半AngularJS的方式，这么做不好。这里的问题在于开发者尝试在 AngularJS的环境里“do jQuery”。这么做总会有一些问题。视图是official record（译者注：作者可能想表达视图是一等公民）。在一个directive外，绝不要改变DOM。所有的directive都应用在试图上，意图非常清晰。
记住：不要设计，然后写标签。你需要架构，然后设计。
数据绑定
这是到现在为止最酷的AngularJS特性。这个特性使得前面提到的很多DOM操作都显得不再需要。AngularJS会自动更新视图，所以你自己不用这么做！在jQuery里，我们响应事件然后更新内容，就像这样：
$.ajax({
url: '/myEndpoint.json',
success: function ( data, status ) {
$('ul#log').append('<li>Data Received!</li>');
}
});
对应的视图:
<ul class="messages" id="log"> </ul>
除了要考虑多个方面，我们也会遇到前面视图中的问题。但是更重要的是，需要手动引用并更新一个DOM节点。如果我们想要删除一个log条目，也需要针对DOM编码。那么如何脱离DOM来测试这个逻辑？如果想要改变展现形式怎么办？
这有一点凌乱琐碎。但是在AngularJS里，可以这样来实现：
$http('/myEndpoint.json').then(function (response) {
$scope.log.push({
msg: 'Data Received!'
});
});
视图看起来是这个样子的：
<ul class="messages"> <li ng-repeat="entry in log"></li> </ul>
但是其实还可以这样来做：
<div class="messages"> <div class="alert" ng-repeat="entry in log"> </div> </div>
现在如果我们想使用Bootstrap的alert boxes，而不是一个无序列表，根本不需要改变任何的controller代码！更重要的是，不论log在何处或如何被更新，视图便会随之更新。自动的。巧妙！
尽管我没有在这里展示，数据绑定其实是双向的。所以这些log信息在视图里也可以是可编辑的。只需要这么做：
<input ng-model="entry.msg" />
。简单快乐。
清晰的模型（Model）层
在jQuery里，DOM在一定程度上扮演了模型的角色。但在AngularJS中，我们有一个独立的模型层可以灵活的管理。完全与视图独立。这有助于上述的数据绑定，维护了关注点的分离（独立的考虑视图和模型），并且引入了更好的可测性。后面还会提到这点。
关注点分离
上面所有的内容都与这个愿景相关：保持你的关注点分离。视图负责展现将要发生的事情；模型表现数据；有一个service层来实现可复用的任务；在 directive里面进行DOM操作和扩展；使用controller来把上面的东西粘合起来。这在其他的答案里也有叙述，我在这里只增加关于可测试性的内容，在后面的一个段落里详述。
依赖注入
依赖注入帮我们实现了关注点分离。如果你来自一个服务器语言（java或php），可能对这个概念已经非常熟悉，但是如果你是一个来自jQuery的客户端开发者，这个概念可能看起来有点傻而多余。但其实不是的。。。
大体来讲，DI意味着可以非常自由的声明组件，然后在另一个组件里，只需要请求一个该组件的实例，就可以得到它。不需要知道（关心）加载顺序，或者文件位置，或类似的事情。这种强大可能不会立刻显现，但是我只提供一个（常见。。）的例子：测试。
就说在你的应用里，我们需要一个服务通过REST API来实现服务器端存储，并且根据不同的应用状态，也有可能使用（客户端）本地存储。当我们运行controller的测试时，不希望必须和服务器交互 —— 毕竟是在测试controller逻辑。我们可以只添加一个与本来使用的service同名的mock service，injector会确保controller自动得到假的那个service —— controller不会也不需要知道有什么不同。
说起测试……
4. 总是 —— 测试驱动开发
这其实是关于架构的第3节。但是它太重要了，所以我把它单独拿出来作为一个顶级段落。
在所有那些你见过，用过或写过的jQuery插件中，有多少是有测试集的？不多，因为jQuery经不起测试的考验。但是AngularJS可以。
在jQuery中，唯一的测试方式通常是独立地创建附带sample/demo页面的组件，然后我们的测试在这个页面上做DOM操作。所以我们必须独立的开发一个组件，然后集成到应用里。多不方便！在使用jQuery开发时，太多的时间，我们挑选迭代而非测试驱动开发。谁又能责怪我们呢？
但是因为有了关注点分离，我们可以在AngularJS中迭代地做测试驱动开发！例如，想要一个超级简单的directive来展现我们的当前路径。可以在视图里声明：
<a href="/hello" when-active>Hello</a>
OK，现在可以写一个测试：
it('should add "active" when the route changes', inject(function () {
var elm = $compile('<a href="/hello" when-active>Hello</a>')($scope);
$location.path('/not-matching');
expect(elm.hasClass('active')).toBeFalsey();
$location.path('/hello');
expect(elm.hasClass('active')).toBeTruthy();
}));
执行这个测试来确认它是失败的。然后我们可以开始写这个directive了：
.directive('whenActive', function ($location) {
return {
scope: true,
link: function (scope, element, attrs) {
scope.$on('$routeChangeSuccess', function () {
if ($location.path() == element.attr('href')) {
element.addClass('active');
} else {
element.removeClass('active');
}
});
}
};
});
测试现在通过了，然后我们的menu按照请求的方式执行。开发过程既是迭代的也是测试驱动的。太酷了。
5. 概念上，Directives并不是打包的jQuery
你经常会听到“只在directive里做DOM操作”。这是必需的。请给它应有的尊重！
但让我们再深入一点……
一些directive仅仅装饰了视图中已经存在的东西（想想ngClass）并且因此有时候仅仅直接做完DOM操作然后就完事了。但是如果一个 directive像一个“widget”并且有一个模版，那么它也要做到关注点分离。也就是说，模版本身也应该很大程度上与其link和 controller实现保持独立。
AngularJS拥有一整套工具使这个过程非常简单;有了ngClass我们可以动态地更新class；ngBind使得我们可以做双向数据绑定。ngShow和ngHide可编程地展示和隐藏一个元素；以及更多地 —— 包括那些我们自己写的。换句话说，我们可以做到任何DOM操作能实现的特性。DOM操作越少，directive就越容易测试，也越容易给它们添加样式，在未来也越容易拥抱变化，并且更加的可复用和发布。
我见过很多AngularJS新手，把一堆jQuery扔到directive里。换句话说，他们认为“因为不能在controller里做DOM操作，就把那些代码弄到directive里好了”。虽然这么做确实好一些，但是依然是错误的。
回想一下我们在第3节里写的那个logger。即使要把它放在一个directive里，我们依然希望用“Angular Way”来做。它依然没有任何DOM操作！有很多时候DOM操作是必要的，但其实比你想的要少得多！在应用里的任何地方做DOM操作之前，问问你自己是不是真的需要这么做。有可能有更好的方式。
这里有一个示例，展示出了我见过最多的一种模式。我们想做一个可以toggle的按钮。（注意：这个例子有一点牵强、啰嗦，这是为了表达出使用同样方式处理问题的更复杂的情况。）
.directive('myDirective', function () {
return {
template: '<a class="btn">Toggle me!</a>',
link: function (scope, element, attrs) {
var on = false;
$(element).click(function () {
if (on) {
$(element).removeClass('active');
} else {
$(element).addClass('active');
}
on = !on;
});
}
};
});
这里有一些错误的地方。首先，jQeury根本没必要出现。我们在这里做的事情都根本用不着jQuery！其次，即使已经将jQuery用在了页面上，也没有理由用在这里。第三，即使假设这个directive依赖jQuery来工作，jqLite(angular.element)在加载后总会使用jQuery！所以我们没必要使用$ —— 用angular.element就够了。第四，和第三条紧密关联，jqLite元素不需要被$封装 —— 传到link里的元素本来就会是一个jQuery元素！第五，我们在前面段落中说过，为什么要把模版的东西混到逻辑里？
这个directive可以（即使是更复杂的情况下！）写得更简单：
.directive('myDirective', function () {
return {
scope: true,
template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',
link: function (scope, element, attrs) {
scope.on = false;
scope.toggle = function () {
scope.on = !$scope.on;
};
}
};
});
再一次地，模版就在模版里，当有样式需求时，你（或你的用户）可以轻松的换掉它，不用去碰逻辑。重用性 —— boom！
当然还有其他的好处，像测试 —— 很简单！不论模版中有什么，directive的内部API从来不会被碰到，所以重构也很容易。可以不碰directive就做到任意改变模版。不论你怎么改，测试总是通过的。
所以如果directive不仅仅是一组类似jQuery的函数，那他们是什么？Directive实际是HTML的扩展。如果HTML没有做你需要它做的事情，你就写一个directive来实现，然后就像使用HTML一样使用它。
换句话说，如果AngularJS库没有做的一些事情，想想开发团队会如何完成它来配合ngClick，ngClass等。
总结
不要用jQuery。连include也不要。它会让你停滞不前。如果遇到一个你认为已经知道如何使用jQuery来解决的问题，在使用$之前，试试想想如何在AngularJS的限制下解决它。如果你不知道，问！20次中的19次，最好的方式不需要jQuery。如果尝试使用jQuery会增加你的工作量。
这是我目前最长的Stack Overflow回答。事实上，这个答案太长了，我都要填一个Captcha了。但是就如我常说的：能说多时候说的少其实就是懒。
希望这个答案对你有用。