三层架构 MVC MVVM

参考深入理解MVC - 知乎 (zhihu.com)

参考来个简单的，MVVM和MVC有什么区别？ - 知乎 (zhihu.com)

参考MVC、MVVM模式的概念与区别 - 理想三旬· - 博客园 (cnblogs.com)

一、三层架构

（1）UI层 表示用户界面

（2）BLL层 表示业务逻辑

（3）DAL层 表示数据访问

三层架构的核心思想是面向接口编程和各层之间的解耦和可替换性

二、MVC

View 视图 View层是界面 

Model 模型 Model层是业务逻辑

Controller 控制器 Controller层用来调度View和Model层，将用户界面和业务逻辑合理的组织在一起，起粘合剂的效果。所以Controller中的内容能少则少，这样才能提供最大的灵活性。

 

比方说，有一个View会提交数据给Model进行处理以实现具体的行为，View通常不会直接提交数据给Model，它会先把数据提交给Controller，然后Controller再将数据转发给Model。假如此时程序业务逻辑的处理方式有变化，那么只需要在Controller中将原来的Model换成新实现的Model就可以了，控制器的作用就是这么简单， 用来将不同的View和不同的Model组织在一起，顺便替双方传递消息，仅此而已。

合理的使用MVC有很多好处，要一一道尽是一件异常困难的任务。在这里我们通过一个反面示例来侧面的证明正确使用MVC的好处与依据。

如前文所言， 很多程序员偏爱于将业务逻辑放在Controller中，我极力反对这种做法，现在我就来证明这中做法的错误性。

我们知道在写程序时，业务逻辑的重复使用是经常要面对的场景。如果业务逻辑写在控制器中，

要重用它的唯一方法就是将它提升到父类之中，通过继承来达到代码复用的效果。但这么做会带来一个巨大的副作用，违背了一项重要的面向对象设计原则：接口隔离。

什么是接口隔离，我在这里简单的讲述一下。通俗一点将，接口隔离就是当一个类需要继承另一个类时，如果被继承的类中有继承的类用不到的方法或属性时，就不要去实现这个继承。如果真的情非得已必须要继承，那么也需要从被继承的类中再提取出一个只包含需要部分功能的新类型，最终去继承这个新类型才是正确的做法。换句话说，实现继承的时候，不要去继承那些用不到的事物。

回到之前的话题，通过继承父控制器的方式复用业务逻辑时，往往会出现为了重用一个方法而继承来一大堆用不到的方法，表面看起来似乎没什么问题，但是这会使代码变的难以理解，长此以往，软件代码会朝着不健康的方向发展。

要知道，使用继承的条件是很苛刻的，我们学习面向对象编程特性时，第一课就是只有满足IS-A（是一个）关系时才可以使用继承，如果仅仅是复用代码，并不是我们使用继承的理由。使用组合是复用代码提倡的方式，也就是所谓的HAS-A（有一个）的关系，相信每个程序员都听过“少用继承，多用组合”这句话，这句话是软件开发业的先驱们千锤百炼总结出来的，值得我们去遵循。

各Model之间是可以相互调用的，Controller也可以无障碍的调用Model，因此将业务代码放在Model中可以灵活的使用组合的方式复用代码。

而Controller之间是不可以相互调用的，要复用代码只能将代码提升至父类，通过继承实现，显然这种做法既不正确，也不灵活，因此完全不提倡。

综上所述，仅仅只是代码复用这一点，也足以将“厚Controller，薄Model”这种不健康的MVC思想打入十八层地狱。

现在我们大概知道了代码应该如何分布于MVC三层之间，知其然，并且也知其所以然。接下来我们再从另一角度深刻剖析MVC，脱它个精光，让它赤条条展示在我们面前。

众所周知，GoF总结过23个设计模式，这23个设计模式是某些特定的编程问题的特效药，这是业内公认的。

MVC是一种模式，但却在GoF总结出的这23个设计模式之外，确切的说它不是一种设计模式，它是多种设计模式的组合，并不仅仅只是一个单独的一个模式。

组成MVC的三个模式分别是组合模式、策略模式、观察者模式，MVC在软件开发中发挥的威力，最终离不开这三个模式的默契配合。那些崇尚设计模式无用论的程序员，请了解只要你们使用MVC，就离不开设计模式。

总结一下，关于MVC各层之间关系所对应的设计模式

View层，单独实现了组合模式

Model层和View层，实现了观察者模式

View层和Controller层，实现了策咯模式

再次回到最前面讨论的业务逻辑应该放在Controller还是Model的问题上，从设计模式的角度讲，策略模式中的策略通常都很小很薄，不会包含太多的内容， Controller是一个策略， 自然不应该在里面放置过多的内容，否则要替换一个新的会相当麻烦，与此同时也会破坏View-Model的观察者模式，仿佛View-Controller之间即实现了策略模式又实现了观察者模式，这种混乱是罪恶的根源，是制造焦油坑让程序员陷入其中无法自拔的罪魁祸首。切忌，应当避免。

MVC就是将这三个设计模式在一起用了，将这三个设计模式弄明白，MVC将毫无神秘感可言。如果不了解这三个设计模式去学习MVC，那不管怎么学总归是一知半解，用的时候也难免不会出想问题。

MVC要实现的目标是将软件用户界面和业务逻辑分离以使代码可扩展性、可复用性、可维护性、灵活性增强。

三、MVVM

 

 与MVC模式一样，MVVM的主要目的是分离视图（View）和模型（Model），ViewModel层封装了界面展示和操作的属性和接口。通过数据绑定，我们可以将View和ViewModel关联在一起，当ViewModel中的数据发生变化时，View也会同步进行更新。

 

MVVM模式解耦了视图和模型。在模式中，每一个视图都有对应的一个ViewModel，同时ViewModel与模型建立联系。当接收到用户请求后，ViewModel获取模型响应数据，并通过数据绑定将相应的视图页面重新渲染。模型层的数据只需要传入ViewModel即可实现视图的同步更新，从而实现了视图和模型之间的松散耦合。

于MVC不同的是，MVC是系统架构级别的，而MVVM只用于单页面上的。因此，MVVM的灵活型号要远大于MVC。如果将这里的M抛开，只看VVM的话，那就是一个组件（如treeview）的设计模式。所以MVVM模式也是组件开发的最佳实践。