本文章含有较多的主观成分，交流为主，大部分内容会参杂个人理解，如有差错，请读者指出

mvc

首先，我们从MVC这个经典的结构开始说起

mvc的结构分层模式（其实说是模式也很勉强，只是单纯的分层），在那个大部分都是服务端直出的年代，这个结构分层的主要目的，是将原本代码直接从Model直接转化为View的这种强耦合形式进行拆分，使得View层和Model层实现弱耦合的形式，从而达到Model/View复用的形式，其实其本质就是将界面层和数据层进行了分离。

直观一点说是，将原本在jsp页面上直接取数据库字段的行为，修改为了由控制器去获得数据，然后Controller拿到数据后，将数据再渲染到view层。这样做的好处是显而易见的

• 将数据库字段和界面进行了解耦，不用因为界面需要，而将同一数据源的数据进行转换后再存一次
• 将界面逻辑进行简化，不需要将每个显示数据的地方进行数据适配
• 当数据源变动时，只需要将Controller中取值部分进行修改，将数据变动在Controller层进行封装，这样可以实现比较优秀的数据复用

当然这里的Controller层并不是一味的指单纯的Controller，它承载的是在view和model中转换者的身份

与其说MVC是种固定的结构，不如说是一种代码结构分层的思想，使得代码的可维护性大大提高，虽然可能层数会比较多，但是代码毕竟是给人看的，不是只是给机器跑的，所以可维护的代码还是很有必要的

前端结构的兴起

随着时间的推移以及用户对交互，对界面的要求不断提高，开发者的精力逐渐不够，无法hold繁杂的产品链

大概在2010年前后，前端和后端的概念形成了

其实一开始，前端的职责很简单，仅仅是为了应付程序员无暇应付的前端css界面，html标签，把字排排上去，前端的职责就基本完成了。

其实在那个时代，前端往往还兼职切切图，设计一下ui，画一下交互，工资还贼低，不过也不像现在的前端那样整天和后端撕逼，往往逻辑部分都是由开发者负责，那个时候前端更多的名字其实是切图工，页面仔

但是呢，随着浏览器支持的功能逐渐变多，前端能做的事情越来越多，程序员的精力就越来越少，导致的结果是根本来不及做交互和一些细节的东西，所以逐渐的，前端承担的东西越来越多

其实这个阶段，比较多的还是jquery时代，前端会个jquery就不错啦，做一些简单的交互，不成结构的那种，往往实现结构差不多了，离结构化还差的很远，所以除非写的人意识很高，不然代码质量依旧是一般般

前端搞了个mvc

分水岭的话，大概是13年前后

一个大时代背景就是那个时候android/ios开发极其火热。本质上，android/ios的开发其实就和前端没什么差别，重点基本都是面向用户界面的展示。由于这个浪潮，界面的结构得到大大的人才流入也得到了大大的加强，首当其冲的是MVC，MVP这种模式在客户端的广泛应用，主要是用于各种界面与数据的使用。前端也得到了大大的加强，毕竟能在app层写，那就能在web写。

同时，那时候有个比较成熟的框架叫做backbone.js，算是比较好的在整个实现了MVC的结构，逐渐的，有原来的程序员转行专门做交互了，也有专门的程序员直接负责后端页面，这种产品做出来往往交互/画面/可维护性/迭代速度/承载功能都会比较优秀。对于用户来说，你后台高不高效其实用户感知的不是很明显，最明显的其实是界面层，界面流畅与否很大程度上会影响用户的体感，所以大势所趋下，专门的前端程序员逐渐诞生了

其实本质上，是后端的逻辑进行了前移，一些与界面交互相关的，全部都交给了前端去做，所以逐渐就有了前端工程师这个职业。

在前端中，将Http+Service层视作为了Model层，将View层和Model层，使用Controller控制并适配，达到了界面的复用/可维护

前端又搞了个mvvm

再之后，是那个时代大热大火的angular.js出现啦，它带领了一个mvvm结构的风潮

何谓mvvm呢？

在mvc，mvp结构中，其实我们的数据的展示，还是需要我们手动去操作view/layout去实现的。这样有个问题就是，当我们多个文件中都有操作一个DOM节点的行为，就会导致这个节点的变化逻辑会非常混乱，甚至毫无规律可循，导致代码的无法维护，这个当然一直都是界面开发者的痛苦，毕竟jquery时代抄起键盘就是干，管他哪里来的，先给我变了再说

而MVVM，本质上是MODEL和VIEW层不做变动，将原本的Controller层修改为了ViewModel层。

ViewModel层，其实是给View层建立了一层Model，起名为ViewModel。

ViewModel是和视图层进行了双向绑定的。（重点）

双向绑定实现的效果就是，当ViewModel变了，View自然跟着响应式的变，而当View变了，ViewModel数据自动跟着变化

当我需要变动view的上展示的数据时，不需要操作view的dom，而是修改view上节点对应的数据的viewModel即可。这样的好处就是，将修改dom节点的入口进行了规避，防止多处地方对一个view进行多次的复杂修改，导致代码的不可维护。

而在angular.js中，其实mvvm中还有一层controller层（1.3版本以后）。但是controller层在angularjs中被大大的弱化了，它的主要作用是操控viewModel，以及让viewModel和model建立起链接，相当于一个适配器。当我service层变化时，只需要修改controller层与service层的适配，即可大幅度的提升界面的可复用性

当然，如果要仔细谈论双向绑定，可能需要另起一篇了，这里不展开细说，本质上是通过订阅发布的方式实现的

同时，由于mvvm的特点，angularjs提供了一个很有趣的东西，名为directive。

directive在很多时候，我都称他为dom的注解/修饰符，它可以对dom进行非侵入性的功能扩展/功能定制，在很多细节修改的时候，会有比较优秀的效果，同时可以实现比较好的单一职责行为，可以将逻辑抽离，对代码复杂度进行大幅度的降低

本质上，是一个标示于dom节点上的字段。当angularjs的compiler解析到它时，对它的compiler/post方法进行使用，在link的回调中，返回它的vm模型，然后交由用户使用改vm模型实现dom节点的修改/扩展/增加事件等一系列行为

相对于react这种函数式思想，很多属性配置由参数传递的行为，我更喜欢angular的这种实现方式，通过指令去扩展一个既有的元素，不需要做很多的配置依赖，毕竟扩展性大大加强了。

图以后在补吧 >_(🌟

结语

写这篇文章的目的主要是为了让自己对于MV*的各种结构进行一个归纳，同时在写作过程中，让自己注意到一些自己可能平时不去了解的东西，通过查阅各种资料完善自己

革命还未成功，同志任需努力～

---