深入理解MVC模式

MVC即Model,View,Controller如上结构图,分别对应模型,视图,控制器。就目前而言，我们大多数人更倾向于将软件的业务逻辑放在Controller里，将数据库访问操作的代码放入Model中，最终软件的代码结构是：View层是界面，Controller是业务逻辑，Model层神数据库访问。
说直白点，大多数人将MVC是当成了三层架构在使用，这样看起来似乎是没什么问题的，毕竟三层架构也是一种和MVC齐名的架构模式。可问题在于用三层架构思路来写MVC，那么写出来的东西既不是三层架构，也不是MVC，成了一个四不像的东西了。
三层架构的核心思想是面向接口编程和各层之间的解耦和可替换性，MVC框架中没有这种概念，因为MVC要面对的问题本不就是三层架构要面对的问题，所以MVC为基础写出来的三层架构是不会举杯三层架构的核心要义。

下面说说MVC的本质原理和正确使用方式，当然这边指的神纯粹的MVC，适合各类软件，不仅仅指Web框架中的变体MVC，然而万变不离其宗，文中所述的MVC思想同样适用于Web开发。

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

View层是界面，Model层神业务逻辑，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思想忘却。

众所周知，GoF总结过23设计模式，这23种设计模式是某些特地的编程问题的特效药，这是业内公认的。
MVC是一种模式，但却在GoF总结出来这23种设计模式之外，准确的说他不是一种设计模式，他是多种设计模式的组合，并不仅仅神一个单独的模式。

组成MVC的三个模式分别是组合模式，策略模式，观察者模式，MVC在软件开发中发挥的威力，最终离不开这三个模式的默契配合。

一下内容以这三个设计模式的知识为基础，如果对着三个设计模式没概念，或许阅读困难。

先说组合模式在MVC中扮演的什么样的角色，

组合模式只在视图层活动，视图层的实现用的就是组合模式，当然这里指的实现是底层的实现，由编程框架厂商做的事情，用不着普通程序员做。

组合模式的类层次结构是树状的， 而我们做Web时视图层是html页面，html的结构不正是树状的吗，这其实就是一个组合模式的应用，只是浏览器厂商已经把界面相关的工作帮我们做掉了，但它确确实实是我们应用MVC的其中一部分，只是我们感觉不到罢了，这也是我们觉得View是实现起来最简单最没有歧义的一层的原因。
除网页以外的其他用户界面程序，如WPF、Android、http://ASP.NET等等都是使用树状结构来组织界面控件对象的，因为组合模式就是从界面设计的通用解决方案总提炼出来的。所以与其说MVC选择了组合模式，还不如说组合模式是必定会存在MVC中的，因为只要涉及到用户界面，组合模式就必定存。事实上即使不理解组合模式，也不影响程序员正确的使用MVC，组合模式本就存在于程序员接触不到的位置。
然而，观察者模式和策略模式就显得比较重要，是实实在在MVC中接触的到的部分。
观察者模式有两部分组成，被观察的对象和观察者，观察者也被称为监听者。对应到MVC中，Model是被观察的对象，View是观察者，Model层一旦发生变化，View层即被通知更新。View层和Model层互相之间是持有引用的。 我们在开发Web MVC程序时，因为视图层的html和Model层的业务逻辑之间隔了一个http，所以不能显示的进行关联，但是他们观察者和收听者的关系却没有改变。当View通过http提交数据给服务器，服务器上的Model接受到数据执行某些操作，再通过http响应将结果回送给View，View（浏览器）接受到数据更新界面，这不正是一个接受到通知并执行更新的行为吗，是观察者模式的另一种表现形式。
但是，脱离Web，当通过代码去纯粹的表示一个MVC结构的时候，View和Model间无疑是观察者和被观察的关系，是以观察者模式为理论基础的。即使在Web中因为http壁垒的原因导致真正的实现有点走样，但是原理核心和思路哲学却是不变的。
最后是策略模式。策略模式是View和Controller之间的关系，Controller是View的一个策略，Controller对于View是可替换的， View和Controller的关系是一对多，在实际的开发场景中，也经常会碰到一个View被多个Controller引用，这即使策咯模式的一种体现，只是不那么直观而已。

总结一下，关于MVC各层之间关系所对应的设计模式
View层，单独实现了组合模式
Model层和View层，实现了观察者模式
View层和Controller层，实现了策咯模式
MVC就是将这三个设计模式在一起用了，将这三个设计模式弄明白，MVC将毫无神秘感可言。如果不了解这三个设计模式去学习MVC，那不管怎么学总归是一知半解，用的时候也难免不会出想问题。
再次回到最前面讨论的业务逻辑应该放在Controller还是Model的问题上，从设计模式的角度讲，策略模式中的策略通常都很小很薄，不会包含太多的内容， Controller是一个策略， 自然不应该在里面放置过多的内容，否则要替换一个新的会相当麻烦，与此同时也会破坏View-Model的观察者模式，仿佛View-Controller之间即实现了策略模式又实现了观察者模式，这种混乱是罪恶的根源，是制造焦油坑让程序员陷入其中无法自拔的罪魁祸首。切忌，应当避免。