这里讲述了MVC的设计思想。

近期，币币生息的陈哥让我重新组建代码架构，他让我按照MVC的设计模式来，经过查阅相关资料，我会将我的想法搬上来。

参考文章

深入理解MVC
代码结构中Dao，Service，Controller，Util，Model是什么意思？

原文内容

知乎

首先我想搬运两篇文章，第一篇是知乎的文章。

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

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

博客

内容大纲：

1.为什么需要一个好的代码结构
2.什么样才是一个好的结构
3.每一个分类代表什么含义
4.是否适用于WEB，Android和IOS？
5.进一步的学习的话，是要学习系统架构么？

为什么需要一个好的代码结构

好的代码结构并不仅仅是为了看上去清晰，它更像是我们对一个系统的拆解和组装。
好的代码结构可以让你在遇到代码交接这种天理不容的情况时，减少提刀砍人的可能性。
好的代码结构可以让多人协作开发更容易，而不会缠缠绵绵到天涯，再相爱相杀。

我们经常形容一个坏的代码结构，像屎一样。

我们称它为一坨，说真的，接手过烂代码之后，真的找不到比屎更能描述自己感受的词了。

“屎”代表着混乱，一坨，各种杂质。接手一堆烂代码的难度就像是用一坨屎来做沙画。

有时候我们还会用一团毛线来形容代码，大概是这样的。

对的，这种感受是绝对不会错的。而我们要做的就是把这团毛线，变成像瑞士军刀一样的清晰。

你们觉得哪个更有成就感？

什么样才是一个好的结构

好的结构应该保持单一职责。
好的结构应该是通用的。
好的结构应该是有明确定义的。

这其实就是所谓的脚手架提供的最大的价值，一般而言，Java，Android，IOS都有一套明确的框架体系，JS本来没有，后来有了，然后。。他们就打起来了。

就像。。。他们一样。

该喷火的喷火，该喷水的喷水，每个人分工都很明确。

每一个分类代表什么含义

Model

Model是模型，一般而言，会有人分的更细，VO，DTO等等。我并不推荐分的更细，这个Model常常和持久化的数据一一对应，如Mysql和MongoDB。

Model承载的作用就是数据的抽象，描述了一个数据的定义，Model的实例就是一组组的数据。整个系统都可以看成是数据的流动，既然要流动，就一定是有流动的载体。

这个红圈标的就是Model。它就应该是一个纯数据的集合，就是被各种东西传来传去，被各种加工处理的数据团。

通常会有很多Model，一条业务流就是对应一条或者多条数据流，拿知乎为例子。

文章是一个Model，一般叫Article，包括Title，Summary，Author，Content等等。

评论也是一个Model，一般叫Comment，包括Content，userID等等。

对于初学者而言，第一个要学会，就是建模，把业务逻辑映射成数据模型。

Util

Util是工具的意思，一般来说，常常用来描述和业务逻辑没有关系的数据处理。

Util一般要和私有方法对比：私有方法一般来说是只是在特地场景下使用的，私有方法越多，代码结构越乱。常见的重构策略就是首先从一个越长行数的代码里抽象出若干个私有方法，然后再抽出公用的Util。

如果有可能，尽可能的少用私有方法，而是把他换成一个公用的Util，代表他和业务逻辑是不相关的。通常命名也是ArticleUtil，CommentUtil之类的。

像这种打包，不管是充气娃娃还是别的什么东西，都打包。你可以理解为图中的黑衣人就是一个Util。

某中程度上也会跟Service有点接近。但是Service一般而言，都是包含有业务逻辑的，很少能做单元测试。

Util一般来说，就是一个明确的输入和一个明确的输出结果。单元测试中，多数也是来测试Util。

积累好自己的Util是一件很重要的事儿。

Service

Service比Util的概念大很多，它的重点是在于提供一个服务。这个服务可能包括一系列的数据处理，也有可能会调用多个Util，或者是调用别的服务。总归一句话，就是，有什么事情，你来找我。

就像这个图上的妹妹一样，她就是一个Service，她能提供什么样的服务？这个是必须定义好的。如果是洗脚，她要帮你脱鞋，要端盆子烫你的脚。这里面，你的脚就是一个Model，盆子里的水相当于Util，不管里面放进去啥都能烫一烫。

帮你脱鞋可以是一个Service，也可以是一个私有函数，也可以是一个Util。看你的是让这个小妹妹帮你脱，还是别的小妹妹脱，还是自动脱鞋机。

如果是你自动脱。。。说明你在Model里面加上了功能，你的脚就不是一个纯粹的数据模型了，而是一个包含业务功能在里面的充血模型。

这样不好。老老实实让小妹妹帮你拖鞋不好么。

Dao

Dao一般而言，都是用来和底层数据库通信，负责对数据库的增删改查。

是的。他就是一个Dao。他从来不关心这些货物要去哪里，他只关心。入库，出库，查询和更换。

所谓的CRUD就是创建，读取，更新，删除。

Dao最好都是要独立出来。

到现在为止，最佳实践就是一个Service只对应一个Dao。Service会做一些额外的检查，如货物是否损坏，入库单是否完整，等等等等。

我并不推荐在Service里调用多个Dao，也推荐在Service里调用多个Service，大多数情况下我都不推荐这么干。

具体原因以后再说，这也是一个开放性的话题。

现在我们分清楚了Model，Util，Service和Dao，可是谁来做总的调度呢？

Controller

控制中心，所有的指令，调度都从这里发出去。

哪一个Service做什么事儿，谁的数据提供给谁，一般而言，都是在Controller里实现的。

Controller也是最常见的容易产生脏代码地方，通常他们会把一些不该放到Controller里东西也放进来。

大概的感觉就是这样的。

我的思考

其实MVC是一种架构思想，但是这种架构思想确实可以让开发或者维护更加容易，也就是可扩展性更强。

下面我来具体讲讲里面的模块。

model

model 可以分为两个部分，一个是 dao ，一个是 model 层，不一定非要叫这个名字。

其中 dao 层是直接对数据库的增删改查，是 sql 语句，而且，据我目前的项目经验来说，我们应该对相同类型的表来创建一个专门的 dao 文件。

具体来说，对于用户，可能分为用户表和用户关系表，对这两个表的操作，就可以组成一个类，然后这个 dao 层的类，是专门用来执行 sql 的。

而 model 是专门对于数据库的逻辑推理或者封装，比如达到什么条件就要执行 dao 层哪个类的方法，当然，这个 model 层也可以更根据场景来细分。

view

这个还没有弄。

controller

这个层其实也包括两个部分，一个是 main ，另一个是 service 。

其中，main 相当于传统意义上的 controller ，但是，并不一定名字非要是 main ，我只是举一个这样的例子。

然后这个 main 文件中，是专门调度各种方法的，代码尽量少，只有调度和返回，而没有业务逻辑处理。

而，业务的逻辑处理要放在 service 中，我们建立这个文件夹，在里面放上各种业务逻辑，比如生辰文件、下载，当然，你可以根据喜好来划分不同的业务逻辑。

但是，所有的业务逻辑应该是放在 service 中的。

总结

当，客户端来了一个命令，我们首先会在 main 中查询到对应的处理，然后在这个处理命令中找到 service 中具体的业务逻辑处理，根据这个业务逻辑，我们会将数据库的判断逻辑下放到 model 中，然后model 再调 dao 层，执行具体的 sql 语句，返回的结果传给 view 或者 service 继续处理。