深刻理解MVC

MVC无人不知，可不少程序员对MVC的概念的理解彷佛有误，换言之他们一直在错用MVC，尽管即便如此软件也能被写出来，然而软件内部代码的组织方式倒是不科学的，这会影响到软件的可维护性、可移植性，代码的可重用性。

 

MVC即Model、View、Controller即模型、视图、控制器。我在和同行讨论技术，阅读别人的代码时发现，不少程序员倾向于将软件的业务逻辑放在Controller里，将数据库访问操做的代码放在Model里。

 

最终软件（网站）的代码结构是，View层是界面，Controller层是业务逻辑，Model层是数据库访问。

 

不知道你们知不知道另一种软件开发模式三层架构，它和MVC类似之处是也分为三层，分别是UI层表示用户界面，BLL层表示业务逻辑，DAL层表示数据访问。三层架构曾经红极一时，MVC大行其道以后它就销声匿迹了， 可如今看来， 它彷佛只是改头换面， 装扮成MVC的样子，而且深受程序员们的欢迎，由于它的这种分层方式和前文描述的MVC一模一样。

 

再说的直白点，不少程序员将MVC当成了三层架构在用，这看起来彷佛没什么问题，毕竟三层架构也是一种和MVC齐名的架构模式。可问题在于用三成架构的思路写MVC，那么写出来的东西既不是三成架构也不是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思想打入十八层地狱。

 

如今咱们大概知道了代码应该如何分布于MVC三层之间， 知其然，而且也知其因此然。接下来咱们再从另外一个角度深入剖析MVC，脱它个精光，让它赤条条展现在咱们眼前。

 

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

 

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

 

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

 

注意，如下内容以这三个设计模式的知识为基础，若是对这三个设计模式没概念，或许会阅读困难。

 

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

 

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

 

组合模式的类层次结构是树状的， 而咱们作Web时视图层是html页面，html的结构不正是树状的吗，这其实就是一个组合模式的应用，只是浏览器厂商已经把界面相关的工做帮咱们作掉了，但它确确实实是咱们应用MVC的其中一部分，只是咱们感受不到罢了，这也是咱们以为View是实现起来最简单最没有歧义的一层的缘由。

 

除网页之外的其余用户界面程序，如WPF、Android、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之间即实现了策略模式又实现了观察者模式，这种混乱是罪恶的根源，是制造焦油坑让程序员陷入其中没法自拔的罪魁祸首。切忌，应当避免。

 

注：此文核心思想来自《head first设计模式》