網際網路系統中的程式碼怎麼分層？

適合受眾：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年以內的各種工程師。

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

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