【修真院「善良」系列之十六】代碼結構中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年之內的各類工程師。