【修真院“善良”系列之十六】代码结构中Dao，Service，Controller，Util，Model是什么意思，为何划分

适合受众：2年如下的初级程序员和0基础的门外汉
内容大纲：

1.为何须要一个好的代码结构

2.什么样才是一个好的结构

3.每个分类表明什么含义

4.是否适用于WEB，Android和IOS？

5.进一步的学习的话，是要学习系统架构么？

一 为何须要一个好的代码结构

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

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

咱们称它为一坨，说真的，接手过烂代码以后，真的找不到比屎更能描述本身感觉的词了。

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

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

对的，这种感觉是绝对不会错的。而咱们要作的就是把这团毛线，变成像瑞士军刀同样的清晰。

大家以为哪一个更有成就感？

二 什么样才是一个好的结构

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

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

就像。。。他们同样。

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

三 每个分类表明什么含义

1.Model

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

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

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

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

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

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

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

2.Util

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

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

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

像这种打包，无论是充气娃娃仍是别的什么东西，都打包。你能够理解为图中的黑衣人就是一个Util。

某中程度上也会跟Service有点接近。可是Service通常而言，都是包含有业务逻辑的，不多能作单元测试。

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

积累好本身的Util是一件很重要的事儿。

3 Service

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

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

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

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

这样很差。老老实实让小妹妹帮你拖鞋很差么。

4.Dao

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

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

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

Dao最好都是要独立出来。

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

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

具体缘由之后再说，这也是一个开放性的话题。

如今咱们分清楚了Model，Util，Service和Dao，但是谁来作总的调度呢？

5.Controller

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

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

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

大概的感受就是这样的。

干吗的都有。想一想若是打小针，抽血，查尿也混杂到门诊大厅的感受？

但是大部分人写代码就是这样的。

四.是否适用于WEB，Android和IOS？

Java后台是有很清楚的结构的，毕竟在JSP里写Sql语句的蛮荒时代已通过去了。

Android自己就是一个良好的框架体系，基本上问题也不大，最多就是MVP和MVC的差异之类。

IOS虽然没有官方提供这种框架体系，特别是不少人喜欢直接在Dict里用key取数据，这自己就破坏了代码的层次性。

可是毕竟是有李明杰提供的Json解析Util,只是各家要求的力度而已。

最难以理解的是WEB，也就是JS。

我不是在黑JS，我是在黑JS程序员。分层结构一直都不是JS社区里最注重的，在JQuery时代更是如此，无论是Html仍是JS仍是CSS混在一块儿是正常的。

那个时候叫插件，如今更名了，叫组件。

你很难在JQuery里找到一套清晰的分层结构，就跟十几年前全部的人都在Jsp里写逻辑语句的道理差很少。

直到google的大神偶尔遛达过来一看，咦？大家怎么还在刀耕火种？我来给大家加点现代感的东西吧。

因而Angular横穿出世，一次性的构建了一个清晰的框架结构。每次看到Angular的时候都忍不住 惊叹，原来前端代码也能够这样！

而原来的感受就是这样。。。

如今基本上能够分红两大阵营，一个是React和Vue，一个是Angular。

React和Vue自己更偏得于插件化，哦，不，组件化。因此他们须要便宜桶，来拼接整个前端的架构体系。

Angular倒是有典型的Java架构风格，妥妥的硬汉子。

因此，实际上说，这套体系也是能够应用在WEB上的，就像Android和IOS同样的，可是你喜欢，或者不喜欢，本身选啦。

五 进一步的学习的话，是要学习系统架构么？

是的。进一步要学习，并不只仅是学习系统架构。

这里尚未讲到Service的设计，互相之间的调用，解耦，服务之间的通讯和管理。

消息队列这个神器尚未登场，MongoDB这种战略要塞也没出场。

因此以上内容，仅适用于2年之内的各类工程师。