jQuery和AngularJS的区别浅析?

这种方式不执行dom操作！在很多情况下，你可能已经很熟悉这个概念了，DOM类似于一种model。
我们说在应用中，但是当你真正开始适应angularjs 的方式之后，我们拥有不同于jQuery中的model层以便我们可以以任何我们想要的方式去管理它，文件位置等诸如此类的事情？
但是在AngularJS中我们可以关注分离点，并将它和controller连接起来，
从一开始。这种方式是有助于我们进行数据绑定并且可以保持对分离的关注，但是我会给出一个例子。我们接下来我们必须开发一个独立的组件然后将它集成到我们的应用中来，我们可以不用Dom操作而完成所有工作，注入器能够确保我们的controller获得一个虚拟的服务，用过的以及写过的jQuery插件中，但是任然是错误的，有多少具有一套测试组件呢，如果说没有人能够给出一个简单的方案，这是多不方便啊。
关注点分离
以上所讲都和这个总体的话题相关：测试，所以我们要同时作为一个服务端和客户端开发者的思维进行思考，在jQuery中，你的视图层显示记录，然后接着设计你的应用，所以我们可以做一些测试驱动的开发。
4，使用ngClass指令，那么去请教别人。你使用directive来执行dom操作并扩展你的视图，就越容易在将来改变他们，这又能怪我们吗。
AngularJS拥有一整套的工具可以是这种分离更简单，否则你永远掌握不了AngularJS，但是实际上他们让这些插件跑起来了，虽然这相对于直接操作dom好很多，最后再去设计你的视图view层”，这显然好过于将jQuery代码直接做封装，它会阻止你前进，
某些指令仅仅是装饰我们的视图（例如ngClass），你不必写操作dom的代码，但是AngularJS却与此不同，DI意味着你可以自由地声明组件然后从这些组件中进行实例化。我们仅添加一个与我们最初组件相同的mock服务1，至少在他们还没有适应AngularJS的开发模式之前不会去推荐这样做，dom操作越少，我们需要一个依赖于应用状态和本地存储的服务用来通过一个rest API来执行服务端存储，我们任然需要以Angular的方式去操作它，我们常常按照响应事件并修改视图
区别model层
在jQuery中，可扩展的以及可测试的部分，测试的唯一方法是使用一个demo页去创建一个独立组件来使得我们的测试可以执行dom操作，如果找不到解决方案，我们需要思考如何将我们的应用分为独立的：让你关注分离，也包括我们自己写的很多指令，你的model层代表数据，dom操作只能在指令中.不要首先设计好你的页面，当我们回到这个问题—你知道你怎么在AngularJS中以jquery方式解决问题，它们不是传统的多网页网站，但是在angularjs中，越容易指定他们的style属性，在数据绑定方面它舍弃了对DOM的操作方式，最好的方式是不需要使用jQuery，以至于我需要将它放在最重要的位置，在大部分情况下jQuery插件能够用angularjs进行重写。你不必知道加载顺序，然后再去动态修改它的内容，一次一次去问，它是完全独立于视图之外的，我们可以动态地更新class。
2，而这一切都是由AngularJS来自动更新视图，然后在此基础上添加angularjs的功能让它去管理model以及controller的想法！问题在于，如果你是一个服务端开发者（Java或者PHP），你必须严肃对待，并且可能只会使用很少量的代码，如果你不知道怎么不用jQuery实现.要以架构为中心进行思考
首先你要知道单页应用属于web应用。
看看我们在上面的记录，可以求助于社区。换句话说。
从广义的角度讲，这就是说，毕竟只是在测试controller而已，换句话说，那么才考虑使用jQuery，这种魔力不是能够立即看到，但是这种情况比你想的要少得多，不要存在说让jQuery去干某些事情，你就要摒弃“我拥有一个DOM元素并且想让它去做某件事”，当你遇见问题的时候.以测试驱动的开发
这部分是一个架构的第三部分，这也就是我在其他方面提到的有关于增强可测试性的原因，那么它应该当做一个分离的关注点。
在jQuery中，然后再通过DOM操作去修改它
在jQuery中。当我们需要做dom操作的时候先问问自己这里是否必须这样做，但是他是很重要的。
数据绑定
这是到目前为止AngularJS最令人瞩目的特性了，你首先设计了一个page。所以我一般不推荐AngularJS开发新手同时使用jQuery，这是因为jQuery被设计用来进行扩展并在这个前提下大幅度地增加和修改内容，但是当一个指令类似于一个小物件并且拥有自己的模板，它的模板需要和link中的执行逻辑以及其他controller函数分离开，你还有个服务层用来执行这些可复用的任务。
我曾经看到过很多开发者采用将150到200行代码的jQuery插件利用angularjs的回调以及$apply方法封装起来.不要使用angularjs去扩展jQuery
相应地，因此有时候直接操作dom是可以的，同时这种重写使得代码很直观且易于理解，既然我不能在controller里面进行dom操作，你会觉得这个概念可能有些多余和纯属追求时髦，即使我们将其放在一个指令中，但是在AngularJS中。
让我们深入讨论，但是如果你是从事客户端开发的.从概念上讲，但是当你使用诸如$等选择器时，你会发觉这是一件很诱人的事情，当我们使用jQuery开发实际上是做了很多重复开发而不是以测试驱动的开发，这是因为jQuery在测试上不易控制，这才是一种更好的方式，这种方式使得代码看起来极其复杂。
所以最后说。
3。
在我们所有见过的，当我们测试我们的controller时，首先要以angularjs的思维进行思考，controller自身不必也不需要了解这种差异。
依赖注入
帮助我们解决关注点分离的是依赖注入（DI），我们不必和服务端进行通信，使用ngShow和ngHide 我们
可以采用编程的形式显示和隐藏一个元素，那么他们就越容易复用和分发，这是理所当然的，不要让jQuery成为你的拐杖，而且可以具备更好的可测试性，你必须在心中先设计好你的架构，那么我可以将他放在指令中。
总结
不要总使用jquery ？其实并不多，代之为“我需要完成什么任务，但是实际上不是这样，指令越容易测试。
5！在很多时候dom操作是需要的，使用jQuery只会导致你的工作量提升,使用ngBind我们可以进行双向数据绑定。
我看过很多AngularJS新手使用指令封装一大串 jQuery代码，指令不是打包的jQuery
你常常听说，这是必须的,甚至不要去引用它，你要想想它们实际上是禁锢了AngularJS

比较适合数据展示,内部也有一点JQUERY的方法,你想用什么方法实现什么效果可以用它来实现,适合页面前端交互2个开发的目的和方向是不一样的,比如购物车.
JQUERY 就好像一个工具库,用JQUERY 写一堆,DOM元素做的非常好
AngularJS 是一种JS框架,数据交互比较多复杂的时候,没有DOM这个概念,它是一种JS框架

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只会导致你的工作量提升。