软件架构模式的演进
MVC、MVP、MVVM 架构模式的主要目标都是将 UI（View） 与业务逻辑/数据（Model）解耦，提高代码的可维护性、可测试性和可扩展性。三者可以看作是架构思想逐步演进的结果。
关于MVC - 1
MVC的兴起主要是由于JSP编写的代码过于臃肿复杂，难以维护。每个JSP文件中同时包含了HTML、CSS、JS、Java的代码，JSP编写的程序架构大概是下图这样的
这种架构的好处是简单快捷，但难以维护的缺点也暴露无遗。可想而知如果页面逻辑复杂一些，一个文件的代码行数可能就会达到3k+。
于是为了让代码更易于维护，开发更加便捷，前后端职责更加清晰，便衍生出了MVC架构模式的框架。前端的展示以模板的形式出现，服务端的MVC架构模式如下图所示
这种分层架构使得代码的职责清晰，更易维护。使用了MVC软件架构的JSP文件只是模板文件，按照模板语法渲染动态内容，原则上不含有JAVA代码。并且前后端形成了一定的分离，前端只需完成开发中的View层。
但这种MVC这种架构模式的前后端职责划分依然不明确，导致了通常由某个开发者同时编写前后端代码，开发者需要学习前端知识，又需要学习服务端知识，这对开发者编程知识的广度的要求太高，学习曲线过陡。
关于MVC - 2
随着Ajax技术风靡全球，前后端的职责也随之变得更为清晰。因为前端可通过Ajax与后端进行数据交互，以此来完成局部刷新。Ajax使得服务器负载与流量消耗降低，并且用户体验也更佳。由此，MVC架构又变成这样了
这种架构模式同样存在问题，它无法承载复杂的业务需求，因为页面内容全都混在一起。因此，前端也亟需一个能够承载复杂业务需求的架构模式，于是前端也使用了类似后端的MVC架构的方案，具备View、Controller、Model
Model：保存应用数据，与后端数据进行交互同步 Controller：负责业务逻辑，根据用户行为修改Model数据 View：视图展示，可视化Model数据
但这样的架构模式在开发过程中不够灵活，比如一个简单的点击事件都需要完整的经过这三个流程。因此在实际开发中看到的架构模式往往是另一种
这种模式显然更加灵活，backbone.js就是采用这种模式的框架。但这种模式所带来的问题是数据流混乱，并且由于View层可以直接操作Model层，因此逻辑能够在View层中编写，又导致了Controller比较单薄。在业务复杂时，Controller层同样会过于复杂。这些问题都导致了Controller层难以进行测试。
关于MVP
MVP是为了解决MVC在前端/客户端里Controller难以测试而诞生的一种架构模式。MVP与MVC比较接近，Presenter可以理解成中间人，负责View与Model之间的数据流动，以此防止View与Model直接交流。
Presenter与Model和View都进行双向交互，这种方式帮助View层成为了被动视图（因为不直接操作Model），并且变得很小。虽然它分离了View与Model，但Presenter层的体积随着程序开发也会逐渐增大，变得难以维护。接下来提到的MVVM则解决了这个问题。
关于MVVM
AngularJS将MVVM架构模式带入了前端，何为MVVM呢？MVVM指的是Model-View-ViewModel。ViewModel是在MVP模式中的Presenter基础之上的进阶版
ViewModel实现一套数据响应式机制，自动相应Model中的数据变化。同时ViewModel会实现一套更新策略，自动的将数据变化转换为视图更新。同时事件监听相应View中用户交互修改Model中的数据。
这种自动响应，自动修改的方式，大大降低了原先在Presenter层中的代码量。在保持松耦合的同时，减少了维护他们关系的代码，使得开发者专注业务逻辑，兼顾开发效率与可维护性。
文章参考于视频：www.bilibili.com/video/BV1Ji…
