写在前面：
我是「沸羊羊_」，昵称来自于姓名的缩写 fyy ，之前呕心沥血经营的博客因手残意外注销，现经营此账号。
本人是个小菜，正向着全栈工程师的方向努力着，文章可能并不高产，也很基础，但每写一篇都在用心总结，请大佬勿喷。
如果您对编程有兴趣，请关注我的动态，一起学习研究。
感谢每位读者！
前言
或许大家都知道 MVC(Model View Controller) 和 MVVM(Model-View-ViewModel) 这两种编程模式，是个老生常谈的问题，但也是前后端都需要思考的问题。小编为了对这两种模式有更深层次的理解，总结一下特此记录。
MVC与三层架构
MVC是：Model(模型)-View(视图)-Controller(控制器) 的缩写，是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。从而很好的达到业务逻辑复用的效果。
上面是百度百科给出的定义，意思就是，将程序代码分为三部分，三者各司其职，在不改变需求的情况下，当与用户交互的视图需要变化时，完全不需要修改业务逻辑，当 V 需要接受数据或获取数据时，通过业务逻辑（C）与 M 打交道，将数据获取到，传递给 V，可以很好的将 V 与 M 解耦。
MVC中的三者都是具体干什么的呢？
Model
Model 作为MVC三层中的最底层，很明显是和数据库打交道的，用来获取和存取数据。但它仅仅是用来操作数据的吗？问题不是这么简单。查阅了不少资料，很多都说 M 层是 “数据层”，只用来和数据库打交道，而业务逻辑是 Controller 负责的。那业务逻辑是不是 Controller 负责的呢？至于答案，还请您听我娓娓道来。
大家应该都知道三层架构：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL），再仔细想想如果业务逻辑放到 Controller ，View 负责与用户看到的显示页面交互，那 MVC 和 三层架构有什么区别？为什么有两种叫法？ 很显然，业务逻辑不是放到Controller 的，那总不能放到 View，难不成是放到 Model 里了 ？把 是前面的难不成去掉，就是放到 Model 里了。
现在来说说为什么业务逻辑放到 Model 里？
MVC模式存在的意义就是要加强软件用户界面和业务逻辑分离以使代码可扩展性、可复用性、可维护性、灵活性。
要想实现可复用性，一定会想到继承，当子类继承父类时，父类中的方法或属性都是子类需要的时候（满足 ( is - a ) ），才可以使用继承。通过继承父类的方式复用业务逻辑时，往往会出现为了重用一个方法而继承来一大堆用不到的方法，表面上看起来似乎没什么问题，但是这会使代码变的难以理解，长此以往， 软件的代码会朝着不健康的方向发展。所以，体现了接口隔离的重要性。但如果是仅复用代码，不是使用继承的理由。继承的使用条件是很苛刻的。使用组合是复用代码提倡的方式，也就是（has - a）的关系，所谓的“合成复用”原则，就是提倡用组合代替继承。这个原则是很多先驱们总结出来的经验，值得我们去遵循。
Model 层包括了数据承载 Bean 和 业务处理 Bean，其中业务处理 Bean 分为 Service 和 Dao，分别对应业务逻辑和数据库操作，相应的，他们对应的是三层结构中的 Service（BLL）层和 Dao (DAL) 层。
V 与 C
三层架构中的UI层简单的说就是跟用户发生直接关系的层，MVC中的V和C就是这样的存在，所以MVC中的V和C均属于三层架构的UI层。
MVC图解
上面的图片很好的解释了 MVC三层之间的联系，Controller 和 View 中间，Controller 和 Model 中间都有两条线，像不像公路上的车道线，其中的含义也是一样，Controller 可以访问 Model和 View ，但 Model 和 View 不能访问 Controller。而且 Model 与 View 中间有两条黄色实线，代表不能直接访问，只能通过 Controller 去间接访问。正如我们程序中一样，View 的视图层，不能直接和 Model 进行交互，需要通过 Controller 去打交道，这样很好的做到了 Model和View 的解耦。
MVVM模式
MVVM (Model-View-ViewModel) 本质上是 MVC 的改进版，在前端页面中，Model 用 JavaScript 表示，View 负责显示，通过 ViewModel 使 Model 和 View 实现分离，解耦合。VM负责把Model 的数据同步到 View，把View 的修改同步到 Model。MVVM中有双向绑定的思想，非常方便，实际上，是底层的VM帮我们实现双向绑定，大大提高开发人员的开发效率。
MVVM的设计思想：关注Model的变化，让MVVM框架去自动更新DOM的状态，从而把开发者从操作DOM的繁琐步骤中解脱出来！
MVVM模式优点
- 低耦合，视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
- 可重用性，可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
- 独立开发，开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计。
小编有话说
对于一个全栈开发工程师来说，懂前端才会开发出更好的后端程序（不懂前端的后端工程师会设计出非常难用的API），懂后端才会开发出更好的前端程序。程序设计的基本思想在前后端都是通用的，两者并无本质的区别。这和“不想当厨子的裁缝不是好司机”是一个道理。