我们先从计算机开始说起好吧,因为特殊的需求有了我们的计算机,编程语言也有刚开始的机器语言到汇编语言,到我们叙述的前端的Vue.js也就是尤大大发明的前端框架 前端也有自己的历史,也有自己的故事,当然也有自己的算法,我们现在主流的前端脚本语言例如有ts,js,等,主要是因为其它的咱们也不咋用,不是没有哈。就像框架一样,我们谈论主流的框架. js和ts最主要区别就是一个是弱类型的,一个是强类型的,这是毋庸置疑的了,我们去用它配合框架或者html也行总之就是完成一个网页,有很多人说js是一个前端的灵魂,当然这个吧也是肯定的,你如果光靠css自然也是很鸡肋的,我拿一个简单的例子说吧,你网页是要实现交互效果对不对,你没有这些,全是图片那就是一个全静态了,当然也不是说,你有了js就一定变成动态了,这倒是不一定,但是没有肯定不行. 既然是说了多前端的强大,我们在没有框架以前哈,当然犹如各位大佬想的一样,刚开始确确实实也是前后端不分离的,但是后期呢,因为这个确实不方便也不得不分离,那这里才是技术的开始了,也就是说,我们从刚开始的跨域,然后又去解决跨域问题,但是我讲的主要不是这个问题,我们还是开始从MVC开始说吧,其实要知道一件事情,我们前端那些MVC其实刚开始也是由后端命名的好像是的, MVC：在Controller里面把Model的数据赋值给View
-
把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要Controller换成另外一个Controller就行了。
-
观察者模式可以做到多视图同时更新。
缺点
1、Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是无法验证的。 2、View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。
Model: 模型（用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法） View: 视图（渲染页面） Controller: 控制器（M和V之间的连接器，用于控制应用程序的流程，及页面的业务逻辑） MVVM架构模式
它是将“数据模型数据双向绑定”的思想作为核心，因此在View和Model之间没有联系，通过ViewModel进行交互，而且Model和ViewModel之间的交互是双向的，因此视图的数据的变化会同时修改数据源，而数据源数据的变化也会立即反应到View上。
优点
1、高可维护性。解决了MVC大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。
2、简化测试。View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。
缺点
1、对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。 2、 过于简单的图形界面不适用，或说牛刀杀鸡。
Model：代表数据模型，也可以 在 Model 中定义数据修改和操作的业务逻辑。 View：视图，代表 UI 组件，它负责将数据模型转化成 UI 展现出来。 ViewModel: 是一个同步 View 和 Model 的对象。
MVP特点：
-
M、V、P之间双向通信。
-
View 与 Model 不通信，都通过 Presenter 传递。Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。
-
View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
-
Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，这样就可以重用。不仅如此，还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试–从而不需要使用自动化的测试工具。 MVP优点：
-
模型与视图完全分离，我们可以修改视图而不影响模型；
-
可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
-
我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
-
如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
MVP缺点： 视图和Presenter的交互会过于频繁，使得他们的联系过于紧密。也就是说，一旦视图变更了，presenter也要变更。