以下文章轉(zhuǎn)載自知乎,暗滅-京華九月秋近寒，浮沉半生影長單.

【修真院“善良”系列之十六】代碼結構中Dao，Service，Controller，Util，Model是什么意思，為什么劃分

暗滅

京華九月秋近寒，浮沉半生影長單

已關注

適合受眾：2年以下的初級程序員和0基礎的門外漢

內(nèi)容大綱：

1.為什么需要一個好的代碼結構

2.什么樣才是一個好的結構

3.每一個分類代表什么含義

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

5.進一步的學習的話，是要學習系統(tǒng)架構么？

一? 為什么需要一個好的代碼結構

好的代碼結構并不僅僅是為了看上去清晰，它更像是我們對一個系統(tǒng)的拆解和組裝。

好的代碼結構可以讓你在遇到代碼交接這種天理不容的情況時，減少提刀砍人的可能性。

好的代碼結構可以讓多人協(xié)作開發(fā)更容易，而不會纏纏綿綿到天涯，再相愛相殺。

我們經(jīng)常形容一個壞的代碼結構，像屎一樣。

我們稱它為一坨，說真的，接手過爛代碼之后，真的找不到比屎更能描述自己感受的詞了。

“屎”代表著混亂，一坨，各種雜質(zhì)。接手一堆爛代碼的難度就像是用一坨屎來做沙畫。

有時候我們還會用一團毛線來形容代碼，大概是這樣的。

對的，這種感受是絕對不會錯的。而我們要做的就是把這團毛線，變成像瑞士軍刀一樣的清晰。

你們覺得哪個更有成就感？

二? 什么樣才是一個好的結構

好的結構應該保持單一職責。

好的結構應該是通用的。

好的結構應該是有明確定義的。

這其實就是所謂的腳手架提供的最大的價值，一般而言，Java，Android，IOS都有一套明確的框架體系，JS本來沒有，后來有了，然后。。他們就打起來了。

就像。。。他們一樣。

該噴火的噴火，該噴水的噴水，每個人分工都很明確。

三? 每一個分類代表什么含義

1.Model

Model是模型，一般而言，會有人分的更細，VO，DTO等等。我并不推薦分的更細，這個Model常常和持久化的數(shù)據(jù)一一對應，如Mysql和MongoDB。

Model承載的作用就是數(shù)據(jù)的抽象，描述了一個數(shù)據(jù)的定義，Model的實例就是一組組的數(shù)據(jù)。整個系統(tǒng)都可以看成是數(shù)據(jù)的 流動，既然要流動，就一定是有流動的載體。

這個紅圈標的就是Model。它就應該是一個純數(shù)據(jù)的集合，就是被各種東西傳來傳去，被各種加工處理的數(shù)據(jù)團。

通常會有很多Model，一條業(yè)務流就是對應一條或者多條數(shù)據(jù)流，拿知乎為例子。

文章是一個Model，一般叫Article，包括Title，Summary，Author，Content等等。

評論也是一個Model，一般叫Comment，包括Content，userID等等。

對于初學者而言，第一個要學會，就是建模，把業(yè)務邏輯映射成數(shù)據(jù)模型。

2.Util

Util是工具的意思，一般來說，常常用來描述和業(yè)務邏輯沒有關系的數(shù)據(jù)處理。

Util一般要和私有方法對比：私有方法一般來說是只是在特地場景下使用的，私有方法越多，代碼結構越亂。常見的重構策略就是首先從一個越長行數(shù)的代碼里抽象出若干個私有方法，然后再抽出公用的Util。

如果有可能，盡可能的少用私有方法，而是把他換成一個公用的Util，代表他和業(yè)務邏輯是不相關的。通常命名也是ArticleUtil，CommentUtil之類的。

像這種打包，不管是充氣娃娃還是別的什么東西，都打包。你可以理解為圖中的黑衣人就是一個Util。

某中程度上也會跟Service有點接近。但是Service一般而言，都是包含有業(yè)務邏輯的，很少能做單元測試。

Util一般來說，就是一個明確的輸入和一個明確的輸出結果。單元測試中，多數(shù)也是來測試Util。

積累好自己的Util是一件很重要的事兒。

3 Service

Service比Util的概念大很多，它的重點是在于提供一個服務。這個服務可能包括一系列的數(shù)據(jù)處理，也有可能會調(diào)用多個Util，或者是調(diào)用別的服務。總歸一句話，就是，有什么事情，你來找我。

就像這個圖上的妹妹一樣，她就是一個Service，她能提供什么樣的服務？這個是必須定義好的。如果是洗腳，她要幫你脫鞋，要端盆子燙你的腳。這里面，你的腳就是一個Model，盆子里的水相當于Util，不管里面放進去啥都能燙一燙。

幫你脫鞋可以是一個Service，也可以是一個私有函數(shù)，也可以是一個Util。看你的是讓這個小妹妹幫你脫，還是別的小妹妹脫，還是自動脫鞋機。

如果是你自動脫。。。說明你在Model里面加上了功能，你的腳就不是一個純粹的數(shù)據(jù)模型了，而是一個包含業(yè)務功能在里面的充血模型。

這樣不好。老老實實讓小妹妹幫你拖鞋不好么。

4.Dao

Dao一般而言，都是用來和底層數(shù)據(jù)庫通信，負責對數(shù)據(jù)庫的增刪改查。

是的。他就是一個Dao。他從來不關心這些貨物要去哪里，他只關心。入庫，出庫，查詢和更換。

所謂的CRUD就是創(chuàng)建，讀取，更新，刪除。

Dao最好都是要獨立出來。

到現(xiàn)在為止，最佳實踐就是一個Service只對應一個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后臺是有很清楚的結構的，畢竟在JSP里寫Sql語句的蠻荒時代已經(jīng)過去了。

Android本身就是一個良好的框架體系，基本上問題也不大，最多就是MVP和MVC的差別之類。

IOS雖然沒有官方提供這種框架體系，特別是很多人喜歡直接在Dict里用key取數(shù)據(jù)，這本身就破壞了代碼的層次性。

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

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

我不是在黑JS，我是在黑JS程序員。分層結構一直都不是JS社區(qū)里最注重的，在JQuery時代更是如此，不管是Html還是JS還是CSS混在一起是正常的。

那個時候叫插件，現(xiàn)在改名了，叫組件。

你很難在JQuery里找到一套清晰的分層結構，就跟十幾年前所有的人都在Jsp里寫邏輯語句的道理差不多。

直到google的大神偶爾遛達過來一看，咦？你們怎么還在刀耕火種？我來給你們加點現(xiàn)代感的東西吧。

于是Angular橫穿出世，一次性的構建了一個清晰的框架結構。每次看到Angular的時候都忍不住 驚嘆，原來前端代碼也可以這樣！

而原來的感覺就是這樣。。。

現(xiàn)在基本上可以分成兩大陣營，一個是React和Vue，一個是Angular。

React和Vue本身更偏得于插件化，哦，不，組件化。所以他們需要便宜桶，來拼接整個前端的架構體系。

Angular卻是有典型的Java架構風格，妥妥的硬漢子。

所以，實際上說，這套體系也是可以應用在WEB上的，就像Android和IOS一樣的，但是你喜歡，或者不喜歡，自己選啦。

五 進一步的學習的話，是要學習系統(tǒng)架構么？

是的。進一步要學習，并不僅僅是學習系統(tǒng)架構。

這里還沒有講到Service的設計，互相之間的調(diào)用，解耦，服務之間的通信和管理。

消息隊列這個神器還沒有登場，MongoDB這種戰(zhàn)略要塞也沒出場。

所以以上內(nèi)容，僅適用于2年以內(nèi)的各種工程師。

最后，文中的任何觀點，都一如既往的不客觀，不中正，不權威。

本文中的圖，也是邊寫邊搜的，所以也會不嚴謹。

今天的分享就到這里啦，歡迎大家點贊、轉(zhuǎn)發(fā)、留言、拍磚~

????????技能樹.IT修真院

????????“我們相信人人都可以成為一個工程師，現(xiàn)在開始，找個師兄，帶你入門，掌控自己學習的節(jié)奏，學習的路上不再迷?！?。

????????這里是技能樹.IT修真院，成千上萬的師兄在這里找到了自己的學習路線，學習透明化，成長可見化，師兄1對1免費指導?？靵砼c我一起學習吧~

我的邀請碼：17742750，或者你可以直接點擊此鏈接：http://www.jnshu.com/login/1/17742750