為什么需要一個好的代碼結(jié)構(gòu)？
不點藍(lán)字關(guān)注，我們哪來故事？
一、為什么需要一個好的代碼結(jié)構(gòu)
3.?好的代碼結(jié)構(gòu)可以讓多人協(xié)作開發(fā)更容易，而不會纏纏綿綿到天涯，再相愛相殺。
我們經(jīng)常形容一個壞的代碼結(jié)構(gòu)，像屎一樣。
我們稱它為一坨，說真的，接手過爛代碼之后，真的找不到比屎更能描述自己感受的詞了。
“屎”代表著混亂，一坨，各種雜質(zhì)。接手一堆爛代碼的難度就像是用一坨屎來做沙畫。
有時候我們還會用一團毛線來形容代碼，大概是這樣的。
對的，這種感受是絕對不會錯的。而我們要做的就是把這團毛線，變成像瑞士軍刀一樣的清晰。
你們覺得哪個更有成就感？
二、什么樣才是一個好的結(jié)構(gòu)
好的結(jié)構(gòu)應(yīng)該保持單一職責(zé)。
好的結(jié)構(gòu)應(yīng)該是通用的。
好的結(jié)構(gòu)應(yīng)該是有明確定義的。
這其實就是所謂的腳手架提供的最大的價值，一般而言，Java，Android，IOS都有一套明確的框架體系，JS本來沒有，后來有了，然后。。他們就打起來了。
就像。。。他們一樣。
該噴火的噴火，該噴水的噴水，每個人分工都很明確。
三、每一個分類代表什么含義
1. Model
Model是模型，一般而言，會有人分的更細(xì)，VO，DTO等等。我并不推薦分的更細(xì)，這個Model常常和持久化的數(shù)據(jù)一一對應(yīng)，如Mysql和MongoDB。
Model承載的作用就是數(shù)據(jù)的抽象，描述了一個數(shù)據(jù)的定義，Model的實例就是一組組的數(shù)據(jù)。整個系統(tǒng)都可以看成是數(shù)據(jù)的 流動，既然要流動，就一定是有流動的載體。
這個紅圈標(biāo)的就是Model。它就應(yīng)該是一個純數(shù)據(jù)的集合，就是被各種東西傳來傳去，被各種加工處理的數(shù)據(jù)團。
通常會有很多Model，一條業(yè)務(wù)流就是對應(yīng)一條或者多條數(shù)據(jù)流，拿知乎為例子。
文章是一個Model，一般叫Article，包括Title，Summary，Author，Content等等。
評論也是一個Model，一般叫Comment，包括Content，userID等等。
對于初學(xué)者而言，第一個要學(xué)會，就是建模，把業(yè)務(wù)邏輯映射成數(shù)據(jù)模型。
2. Util
Util是工具的意思，一般來說，常常用來描述和業(yè)務(wù)邏輯沒有關(guān)系的數(shù)據(jù)處理。
Util一般要和私有方法對比：私有方法一般來說是只是在特地場景下使用的，私有方法越多，代碼結(jié)構(gòu)越亂。常見的重構(gòu)策略就是首先從一個越長行數(shù)的代碼里抽象出若干個私有方法，然后再抽出公用的Util。
如果有可能，盡可能的少用私有方法，而是把他換成一個公用的Util，代表他和業(yè)務(wù)邏輯是不相關(guān)的。通常命名也是ArticleUtil，CommentUtil之類的。
像這種打包，不管是充氣娃娃還是別的什么東西，都打包。你可以理解為圖中的黑衣人就是一個Util。
某中程度上也會跟Service有點接近。但是Service一般而言，都是包含有業(yè)務(wù)邏輯的，很少能做單元測試。
Util一般來說，就是一個明確的輸入和一個明確的輸出結(jié)果。單元測試中，多數(shù)也是來測試Util。
積累好自己的Util是一件很重要的事兒。
3. Service
Service比Util的概念大很多，它的重點是在于提供一個服務(wù)。這個服務(wù)可能包括一系列的數(shù)據(jù)處理，也有可能會調(diào)用多個Util，或者是調(diào)用別的服務(wù)。總歸一句話，就是，有什么事情，你來找我。
就像這個圖上的妹妹一樣，她就是一個Service，她能提供什么樣的服務(wù)？這個是必須定義好的。如果是洗腳，她要幫你脫鞋，要端盆子燙你的腳。這里面，你的腳就是一個Model，盆子里的水相當(dāng)于Util，不管里面放進去啥都能燙一燙。
幫你脫鞋可以是一個Service，也可以是一個私有函數(shù)，也可以是一個Util?？茨愕氖亲屵@個小妹妹幫你脫，還是別的小妹妹脫，還是自動脫鞋機。
如果是你自動脫。。。說明你在Model里面加上了功能，你的腳就不是一個純粹的數(shù)據(jù)模型了，而是一個包含業(yè)務(wù)功能在里面的充血模型。
這樣不好。老老實實讓小妹妹幫你拖鞋不好么。
4. Dao
Dao一般而言，都是用來和底層數(shù)據(jù)庫通信，負(fù)責(zé)對數(shù)據(jù)庫的增刪改查。
是的。他就是一個Dao。他從來不關(guān)心這些貨物要去哪里，他只關(guān)心。入庫，出庫，查詢和更換。
所謂的CRUD就是創(chuàng)建，讀取，更新，刪除。
Dao最好都是要獨立出來。
到現(xiàn)在為止，最佳實踐就是一個Service只對應(yīng)一個Dao。Service會做一些額外的檢查，如貨物是否損壞，入庫單是否完整，等等等等。
我并不推薦在Service里調(diào)用多個Dao，也推薦在Service里調(diào)用多個Service，大多數(shù)情況下我都不推薦這么干。
具體原因以后再說，這也是一個開放性的話題。
現(xiàn)在我們分清楚了Model，Util，Service和Dao，可是誰來做總的調(diào)度呢？
5. Controller
控制中心，所有的指令，調(diào)度都從這里發(fā)出去。
哪一個Service做什么事兒，誰的數(shù)據(jù)提供給誰，一般而言，都是在Controller里實現(xiàn)的。
Controller也是最常見的容易產(chǎn)生臟代碼地方，通常他們會把一些不該放到Controller里東西也放進來。
大概的感覺就是這樣的。
干嘛的都有。想想如果打小針，抽血，查尿也混雜到門診大廳的感覺？
可是大部分人寫代碼就是這樣的。
四、是否適用于WEB，Android和IOS？
Java后臺是有很清楚的結(jié)構(gòu)的，畢竟在JSP里寫Sql語句的蠻荒時代已經(jīng)過去了。
Android本身就是一個良好的框架體系，基本上問題也不大，最多就是MVP和MVC的差別之類。
IOS雖然沒有官方提供這種框架體系，特別是很多人喜歡直接在Dict里用key取數(shù)據(jù)，這本身就破壞了代碼的層次性。
但是畢竟是有李明杰提供的Json解析Util,只是各家要求的力度而已。
最難以理解的是WEB，也就是JS。
我不是在黑JS，我是在黑JS程序員。分層結(jié)構(gòu)一直都不是JS社區(qū)里最注重的，在JQuery時代更是如此，不管是Html還是JS還是CSS混在一起是正常的。
那個時候叫插件，現(xiàn)在改名了，叫組件。
你很難在JQuery里找到一套清晰的分層結(jié)構(gòu)，就跟十幾年前所有的人都在Jsp里寫邏輯語句的道理差不多。
直到google的大神偶爾遛達(dá)過來一看，咦？你們怎么還在刀耕火種？我來給你們加點現(xiàn)代感的東西吧。
于是Angular橫穿出世，一次性的構(gòu)建了一個清晰的框架結(jié)構(gòu)。每次看到Angular的時候都忍不住 驚嘆，原來前端代碼也可以這樣！
而原來的感覺就是這樣。。。
現(xiàn)在基本上可以分成兩大陣營，一個是React和Vue，一個是Angular。
React和Vue本身更偏得于插件化，哦，不，組件化。所以他們需要便宜桶，來拼接整個前端的架構(gòu)體系。
Angular卻是有典型的Java架構(gòu)風(fēng)格，妥妥的硬漢子。
所以，實際上說，這套體系也是可以應(yīng)用在WEB上的，就像Android和IOS一樣的，但是你喜歡，或者不喜歡，自己選啦。
五、進一步的學(xué)習(xí)的話，是要學(xué)習(xí)系統(tǒng)架構(gòu)么？
是的。進一步要學(xué)習(xí)，并不僅僅是學(xué)習(xí)系統(tǒng)架構(gòu)。
這里還沒有講到Service的設(shè)計，互相之間的調(diào)用，解耦，服務(wù)之間的通信和管理。
消息隊列這個神器還沒有登場，MongoDB這種戰(zhàn)略要塞也沒出場。
推薦
