起源：zhihu.com/question/58410621/answer/156868800
一 为什么须要一个好的代码构造
- 好的代码构造并不仅仅是为了看上去清晰，它更像是咱们对一个零碎的拆解和组装。
- 好的代码构造能够让你在遇到代码交接这种天理不容的状况时，缩小提刀砍人的可能性。
- 好的代码构造能够让多人合作开发更容易，而不会缠缠绵绵到咫尺，再相爱相杀。
咱们常常形容一个坏的代码构造，像屎一样。
咱们称它为一坨，说真的，接手过烂代码之后，真的找不到比屎更能形容本人感触的词了。
“屎”代表着凌乱，一坨，各种杂质。接手一堆烂代码的难度就像是用一坨屎来做沙画。
有时候咱们还会用一团毛线来形容代码，大略是这样的。
对的，这种感触是相对不会错的。而咱们要做的就是把这团毛线，变成像瑞士军刀一样的清晰。
你们感觉哪个更有成就感？
二 什么样才是一个好的构造
- 好的构造应该放弃繁多职责。
- 好的构造应该是通用的。
- 好的构造应该是有明确定义的。
这其实就是所谓的脚手架提供的最大的价值，一般而言，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年以内的各种工程师。
近期热文举荐：
1.1,000+ 道 Java面试题及答案整顿(2022最新版)
2.劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4.别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞+转发哦！