扩展阅读：为什么需要良好的代码结构？

下雪了：我刚在论坛上开了一个话题：我怎能不留下一团糟？然后我看到这篇文章，这篇文章只是一篇专门回答我话题的文章，所以我把它重新打印为扩展阅读。作者：从原始地址黑暗中获取观众：2年的初级程序员和0级的外行人

内容大纲：

1.为什么需要良好的代码结构

2.什么是好结构

3.每个类别的含义是什么？

4.它适用于WEB，Android和IOS吗？

5.如果您想进一步学习，是否有必要学习系统架构？

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

良好的代码结构不仅仅是为了清晰，它更像是系统的反汇编和组装。一个好的代码结构可以让你在遇到代码处理不当的情况下减少拿刀的可能性。良好的代码结构可以使多个人更容易协作和开发，而不会陷入困境，然后彼此相爱。

我们经常描述像蟑螂这样糟糕的代码结构。

我们称之为一瞥，真的，在接手了坏代码之后，我真的找不到比屎更能描述我感情的词。

“屎”代表混乱，是各种杂质的一瞥。接管一堆坏代码的难度就像使用一瞥沙画一样。

有时我们会使用一堆羊毛来描述代码，这可能就是这种情况。

是的，这种感觉绝对不错。而我们要做的就是将这组纱线转变成与瑞士军刀相同的清晰度。

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

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

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

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

就像.他们一样。

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

三每一个分类代表什么含义

1.型号

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

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

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

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

沈阳小程序设计

文章是一个模型，一般叫条，包括标题，摘要，作者，内容等等。

XX 注释也是一个Model，通常称为Comment，包括Content，userID等。

对于初学者，首先要学习的是将业务逻辑建模并映射到数据模型中。

2.Util

Util是工具的意义。通常，它通常用于描述与业务逻辑无关的数据处理。

Util通常与私有方法相比：私有方法通常仅在特殊情况下使用。私有方法越多，代码结构就越混乱。一种常见的重构策略是首先从较长的代码行中抽象出一些私有方法，然后提取公共Util。

如果可能，请尽可能少地使用私有方法，但将其替换为公共Util，这意味着它与业务逻辑无关。通常命名为ArticleUtil，CommentUtil等。

就像这个包装一样，无论是充气娃娃还是其他东西，它都是包装好的。你可以理解图片中的黑人是一个男人。

在某种程度上也会有点接近服务。但服务通常包含业务逻辑，很少进行单元测试。

Util通常是清晰的输入和清晰的输出。大多数单元测试也用于测试Util。

积累自己的Util是非常重要的。

3服务

服务比Util的概念大得多，其重点是提供服务。此服务可能包括一系列数据处理，或者可能会调用多个Utils，或调用其他服务。总之，是的，有一些东西，你来找我。

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

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

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

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

4.Dao

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

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

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

道最好都是要独立出来。

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

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

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

XX Now we have a clear understanding of Model, Util, Service and Dao, but who is going to do the total scheduling?

5.Controller

Control Center, all instructions, scheduling are sent out from here.

Which Service does what, and whose data is provided to whom, in general, is implemented in the Controller.

The Controller is also the most common place to generate dirty code. Usually they put in something that shouldn't be placed in the Controller.

The general feeling is like this.

Everything is done. Think about the feeling of using a small needle, blood, and urine to the clinic hall.

But most people write code like this.

4. Does it apply to WEB, Android and IOS?

The Java backend has a very clear structure. After all, the wild age of writing Sql statements in JSP has passed.

Android itself is a good framework system, basically the problem is not big, at most the difference between MVP and MVC.

Although IOS does not officially provide such a framework system, especially many people like to use the key to fetch data directly in Dict, which in itself destroys the hierarchy of the code.

But after all, there is JJ's analysis of Util provided by He Mingjie, but it is only the strength of each request.

The most difficult to understand is WEB, which is JS.

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

那个时候叫插件，现在改名了，叫组件。

你很难在JQuery的里找到一套清晰的分层结构，就跟十几年前所有的人都在jsp的里写逻辑语句的道理差不多。

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

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

而原来的感觉就是这样.

现在基本上可以分成两大阵营，一个是阵营和Vue的，一个是有角的。

反应和Vue公司本身更偏得于插件化，哦，不，组件化。所以他们需要便宜桶，来拼接整个前端的架构体系。

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

所以，实际上说，这套体系也是可以应用在WEB上的，就像的Android和IOS一样的，但是你喜欢，或者不喜欢，自己选啦。

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

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

这里还没有讲到服务的设计，互相之间的调用，解耦，服务之间的通信和管理。

XX 消息队列尚未出现，MongoDB的战略要塞尚未出现。

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