先后端分层架构MVC&MVVM

早期

---

 

特色

　　页面由 JSP、PHP 等工程师在服务端生成

　　JSP 里揉杂大量业务代码

　　浏览器负责展示，服务端给什么就展示什么，展示的控制在 Web Server 层

优势

　　简单明快，本地起一个 Tomcat 或 Apache 就能开发，调试什么的都还好，只要业务不太复杂。

缺点

　  前端难以搭建本地环境

　　代码重用性，扩展性，维护性很低

后端 MVC 开发

---

 

特色

• View：进行数据显示。
• Model：用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。
• Controller：处理用户交互，负责转发请求，并对请求进行处理（向模型请求数据或发送数据）

  服务器端的MVC流程：

  客户端发送请求 -> 服务器触发Controller -> 服务器进行Model各类操做 -> 服务器根据Model数据渲染View -> 服务器回复请求，包含了整个View的html -> 客户端从新渲染整个页面，全部的css都又计算了一遍，全部的js都从新执行了一遍，全部的资源都从新请求了一遍（虽然可能已经cache了）

 

优势

　　代码可维护性获得明显好转

　　线上模板的渲染仍是由java来作的，造成的是带有动态数据的html，比较有利于SEO

缺点

　   随着不一样终端的出现，前端的工做量变大。可是前端依然依赖着后端（都在一个项目中进行开发）

　　先后端职责依旧纠缠不清

先后端分离

---

 

特色

　　ajax带来了Web开发革命性的变化。前端和应用服务器分离，前端和后端经过Ajax来通讯。

　　先后端分工，前端使用ajax与后端数据交互，操做视图，甚至控制部分路由，后端提供服务与数据。

 

优势

 　 先后端的分工很是清晰

缺点

　  前端逻辑愈来愈重，愈来愈复杂，路由很差掌控。过度使用ajax不利于SEO。前端不坑重负

　  这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很复杂

前端分层

---

 

特色

　　后端思想在前端进行应用 

　　前端代码变得也须要保存数据、处理数据、生成视图（SPA），这致使了前端 MVC 框架的诞生

　　前端的MVC只是后端MVC中的View里面再去分出来的MVC。前端的MVC是为了解决复杂前端状况下模块化 JS的问题。

　　一个事件的发生是这样的过程：
　　1. 用户和应用产生交互。
　　2. 控制器的事件处理器被触发。
　　3. 控制器从模型中请求数据，并将其交给视图。
　　4. 视图将数据呈现给用户。

　　模型

　　用来存放应用的全部数据对象。好比，可能有一个User模型，用以存放用户列表、他们的属性及全部与模型有关的逻辑；当控制器从服务器抓取数据或建立新的记录时，它就将数据包装成模型实例。也就是说，咱们的数据是面向对象的，任何定义在这个数据模型上的函数或逻辑均可以直接被调用。

　　视图

　　呈现给用户的，用户与之产生交互。在JavaScript应用中，视图大都是由HTML、CSS、JavaScript模板组成的。除了模板中简单的条件语句以外，视图不该当包含任何其余逻辑。
　　将逻辑混入视图之中是编程的大忌，这并非说MVC不容许包含视觉呈现相关的逻辑，只要这部分逻辑没有定义在视图以内便可。咱们将视觉呈现逻辑归类为“视图助手”（helper）：和视图相关的独立的小工具函数。

　　控制器

　　模型和视图之间的纽带。控制器从视图获取事件和输入，对它们（极可能包含模型）进行处理，并相应地更新视图。当页面加载时，控制器会给视图添加事件监听，好比监听表单提交或按钮点击。而后，当用户和你的应用产生交互时，控制器中的事件触发器就开始工做了。

 

后端MVC中的view是前端MCV的所有

 

　　前端MVC流程（前端其实大部分是MV+X，不必定有Controller):

　　客户端根据用户的行为修改客户端Model -> 客户端更新和该Model相关的View -> 客户端Model发送sync请求到服务器，只包含改变了哪些数据 -> 服务器审核数据改动是否合法，只需回复是否修改为功 -> 客户端收到成功，什么都不用作；不成功，则把刚才改的View改回来，而后通知用户。（固然，也能够在客户端的Model里面也加入审核机制，这样对不合法数据的反应更快，但仍是得保留服务器端的审核）

　　比较一下能够看到，前端MVC须要向服务器端传递和接收的数据量都少不少，而前端要作的等待和渲染工做也少了不少。换言之，会提供更快的交互反馈，也意味着更好的用户体验。同时，服务器端的负载也略有下降，由于基本上只须要在数据库上提供一个RESTful API便可。

优势

　　清晰的分工，可让开发并行

　　部署相对独立，产品体验能够快速改进。

缺点

　　开发者在代码中大量调用相同的DOM API, 处理繁琐，操做冗余，使得代码难以维护。

　　大量的DOM 操做使页面渲染性能下降，加载速度变慢，影响用户体验。

　　当 Model 频繁发生变化，开发者须要主动更新到View ；当用户的操做致使Model发生变化，开发者一样须要将变化的数据同步到Model中， 这样的工做不只繁琐，并且很难维护复杂多变的数据状态。

MVVM 模式

---

 

特色

另外一些框架提出 MVVM 模式，用 View Model 代替 Controller。

• Model
• View
• View-Model：简化的 Controller，为 View 提供处理好的数据，不含其余逻辑。

本质：view 绑定 view-model，视图与数据模型强耦合。数据的变化实时反映在 view 上，不须要手动处理。

 

优势　

　　前端应用的复杂程度已不一样往日，暴露出了三个痛点问题：

　　开发者在代码中大量调用相同的DOM API, 处理繁琐，操做冗余，使得代码难以维护。

　　大量的DOM 操做使页面渲染性能下降，加载速度变慢，影响用户体验。

　　当 Model 频繁发生变化，开发者须要主动更新到View ；当用户的操做致使Model发生变化，开发者一样须要将变化的数据同步到Model中， 这样的工做不只繁琐，并且很难维护复杂多变的数据状态。

　　早期 jQuery 的出现就是为了前端能更简洁的操做DOM 而设计的，但它只解决了第一个问题，另外两个问题始终伴随着前端一直存在。

　　MVVM 的出现，完美解决了以上三个问题。

　　MVVM 的三部分：

　　 Model 层表明数据模型，也能够在Model中定义数据修改和操做的业务逻辑；

　　View 表明UI 组件，它负责将数据模型转化成UI 展示出来，

　　ViewModel 是一个同步View 和 Model的对象。

　　View 和 Model 之间并无直接的联系，而是经过ViewModel进行交互。

　　ViewModel 经过双向数据绑定把 View 层和 Model 层链接了起来，而View 和 Model 之间的同步工做彻底是自动的，无需人为干涉，所以开发者只需关注业务逻辑，不须要手动操做DOM, 不须要关注数据状态的同步问题，复杂的数据状态维护彻底由 MVVM 来统一管理。

缺点

　 　 代码不能复用。好比后端依旧须要对数据作各类校验，校验逻辑没法复用浏览器端的代码。若是能够复用，那么后端的数据校验能够相对简单化。
　　 全异步，对 SEO 不利。每每还须要服务端作同步渲染的降级方案。
　　 性能并不是最佳，特别是移动互联网环境下。

 

参考：https://blog.csdn.net/u010924834/article/details/51025127 

　　   https://github.com/lifesinger/blog/issues/184