很多人表示對架構(gòu)沒有任何概念，想了解下架構(gòu)，但是看了網(wǎng)上的一些文章又覺得云里霧里，其實(shí)架構(gòu)遠(yuǎn)沒有那么難，今天從這篇文章開始我來給大家談?wù)劶軜?gòu)，爭取讓大家都看得懂。

1.什么是架構(gòu)?

對于架構(gòu)，業(yè)界從來沒有一個(gè)統(tǒng)一的定義，架構(gòu)一詞最初來自建筑業(yè)，假如我們要蓋一棟大樓，那在完成這么一項(xiàng)重大工程之前肯定需要建造師的建筑圖紙，而這建筑圖紙可以說是建筑業(yè)架構(gòu)的最核心體現(xiàn)，它描述了這棟大樓的外觀、內(nèi)部構(gòu)造、戶型設(shè)計(jì)、材料做法以及設(shè)備、施工等，有了建筑圖紙，才能整體的規(guī)劃整個(gè)工程，從大局出發(fā)，有序的推進(jìn)項(xiàng)目的發(fā)展，最大程度的提高生產(chǎn)力。

所以歸根結(jié)底，架構(gòu)的目的就是為了提高生產(chǎn)力。而軟件領(lǐng)域的架構(gòu)主要體現(xiàn)在模塊之間的「高內(nèi)聚，低耦合」，這六個(gè)字聽起來有點(diǎn)難以理解，其實(shí)通俗來講就是單一職責(zé)的功能封裝成模塊，在模塊內(nèi)部高度聚合，模塊與模塊之間不會(huì)互相依賴，即低耦合。比如我們常用的網(wǎng)絡(luò)庫、圖片加載庫，這都是屬于兩個(gè)模塊，在每個(gè)模塊內(nèi)部功能單一，代碼高度內(nèi)聚，但是網(wǎng)絡(luò)庫與圖片加載庫又不互相依賴，都可以獨(dú)立工作，互不干擾，這就是所謂的低耦合。

而我們追求「高內(nèi)聚，低耦合」的目的很簡單，我們想讓開發(fā)人員只專注于一點(diǎn)，提高開發(fā)效率的同時(shí)，也對代碼的健壯性與擴(kuò)展性有很大好處。試想，如果你做的功能需要同時(shí)跟四個(gè)部門進(jìn)行合作，依賴于他們的模塊，那么你的開發(fā)效率肯定奇低，而且依賴過高，其他部門的代碼稍一改動(dòng)很可能就會(huì)對你產(chǎn)生影響，而且問題還不容易定位，這將是一個(gè)定時(shí)炸彈。

所以，架構(gòu)的重要性不言而喻，但是架構(gòu)有一條原則：千萬不要過度設(shè)計(jì)!

如果你蓋的是棟大樓，你肯定需要建造師的建筑圖紙，但是如果你蓋的是一間茅草屋，你覺得你還需要請個(gè)建造師來先給你設(shè)計(jì)一張建筑圖紙?jiān)匍_工么?可能花在設(shè)計(jì)建筑圖紙的時(shí)間都夠你蓋完了。所以架構(gòu)一定得看不同場景的需求，如果你的工程總共就十來個(gè)文件，那么你在開發(fā)的過程中運(yùn)用各種設(shè)計(jì)模式、考慮各種分層，只會(huì)讓原本簡單的東西復(fù)雜化，還會(huì)增加工作量，這違背了架構(gòu)的初衷。

最原始、最簡單的東西反而是最高效的，只不過我們的項(xiàng)目慢慢變得龐大，那些最原始的框架與結(jié)構(gòu)滿足不了我們的需求了，這個(gè)時(shí)候我們必須從整體出發(fā)重新考慮整個(gè)項(xiàng)目的架構(gòu)，通過架構(gòu)來幫助我們提高生產(chǎn)力，減少重復(fù)繁雜的工作量，提升工作效率。

2.三層架構(gòu)

說到架構(gòu)，就不得不談到最經(jīng)典的三層架構(gòu)的概念，三層架構(gòu)最初是微軟提出的，并且推薦各應(yīng)用程序都應(yīng)該遵守這種分層方式，而現(xiàn)今大多數(shù)應(yīng)用程序基本都遵守這三層分層式架構(gòu)。這三層架構(gòu)分別是：表示層、業(yè)務(wù)層、數(shù)據(jù)訪問層。

我們拿訪問一個(gè)網(wǎng)站來舉個(gè)例子。你在瀏覽器輸入一個(gè)網(wǎng)址，訪問一個(gè)網(wǎng)站的時(shí)候，這中間經(jīng)過了這么一個(gè)過程，用戶在瀏覽器輸入 url，然后瀏覽器向 Server 發(fā)起一個(gè) http 請求，Server 拿到這個(gè) http 請求之后會(huì)根據(jù)相關(guān)的條件到數(shù)據(jù)庫查詢相關(guān)數(shù)據(jù)，然后把數(shù)據(jù)以特定的格式(網(wǎng)站是 html 格式)返回給瀏覽器，瀏覽器再根據(jù)特定數(shù)據(jù)渲染出相應(yīng)頁面。

這其中就對應(yīng)了三層架構(gòu)，首先對用戶來說，瀏覽器就是表示層，它主要是與用戶交互的頁面，根據(jù)用戶的輸入與事件，處理并顯示返回的特定數(shù)據(jù)。我們知道數(shù)據(jù)是一切應(yīng)用程序的基礎(chǔ)，如果沒有數(shù)據(jù)，那么沒有任何意義，所以 Server 端必須要一個(gè)強(qiáng)大的數(shù)據(jù)庫來存儲(chǔ)所有用戶交互產(chǎn)生的數(shù)據(jù)，而對這些數(shù)據(jù)的處理，包括增、刪、改、查就屬于數(shù)據(jù)訪問層。那么連接表示層與數(shù)據(jù)訪問層的就是業(yè)務(wù)邏輯層，這包括后端程序中模型設(shè)計(jì)、驗(yàn)證、業(yè)務(wù)規(guī)則、各種計(jì)算等。

所以后端的架構(gòu)是很復(fù)雜的，它除了有復(fù)雜的業(yè)務(wù)邏輯之外，還有存儲(chǔ)、性能、并發(fā)、負(fù)載均衡等等，所以架構(gòu)師一職最初也是針對服務(wù)端提供的職位。

3.MVC

隨著移動(dòng)端的普及，手機(jī)端的應(yīng)用程序功能越來越大，項(xiàng)目也越來越復(fù)雜，所以移動(dòng)端架構(gòu)也被越來越多的人關(guān)注與重視，但是移動(dòng)端架構(gòu)遠(yuǎn)沒有服務(wù)端復(fù)雜，一是移動(dòng)端的數(shù)據(jù)來源于服務(wù)端，不必有專門的數(shù)據(jù)存儲(chǔ)，最多有本地的緩存以及一些必要的小型數(shù)據(jù)庫，對于一些復(fù)雜的業(yè)務(wù)邏輯也更多的放在服務(wù)端，而且客戶端不必考慮成百上千萬用戶的同時(shí)訪問，移動(dòng)端通常更應(yīng)該把精力專注在 UI、交互、體驗(yàn)上，所以客戶端的架構(gòu)沒有那么重，但是為了讓移動(dòng)端代碼分層更加清晰，代碼擴(kuò)展性更好，以及更好的高內(nèi)聚、低耦合，目前有一系列的移動(dòng)端架構(gòu)方案，大家耳熟能詳?shù)谋热? MVC、MVP、MVVM、Clean 等，今天就先來針對 Android 開發(fā)，來講講 MVC 的概念。

MVC 是 Model(模型)、View(視圖)、Controller(控制器) 的縮寫，其中 View 層處理界面顯示，Controller 層用來處理用戶的交互與事件，Model 層則用來定義實(shí)體對象與處理業(yè)務(wù)邏輯。

這么說難免有點(diǎn)晦澀難懂，我們來拿我們最熟悉的 Android 開發(fā)來舉例。

4.Android MVC

其實(shí) Android 開發(fā)本身默認(rèn)的就是一套 MVC 實(shí)現(xiàn)。

View 層：Android 開發(fā)中的 xml 布局就是我們的 View 層，默認(rèn)情況下也建議 View 都盡量用 xml 實(shí)現(xiàn)，當(dāng)然對于一些復(fù)雜的就需要我們自定義 View 了，自定義 View 同樣也是屬于 View 層，只不過大多數(shù)時(shí)候還是 xml 布局用的最多;

Controller 層：毫無疑問，Android 默認(rèn)也給我們提供了 Controller，就是 Activity & Fragment，仔細(xì)想想，是不是用戶的交互事件，如輸入、點(diǎn)擊、滑動(dòng)等都是在 Activity、Fragment 中處理的?關(guān)于這點(diǎn)有人認(rèn)為 Activity & Fragment 屬于 View 層，這個(gè)我是不認(rèn)可的，View 應(yīng)該專注界面的顯示，Controller 處理用戶的交互，提供給 View 需要的數(shù)據(jù)，從而讓 View 正確的顯示出來，而這都是 Activity & Fragment 的工作。

Model 層：Android 中對 View 與 Controller 有了定義，其實(shí)沒有對 Model 層做定義，而大部分架構(gòu)都不會(huì)對 Model 層做定義，因?yàn)?Model 本身是跟業(yè)務(wù)相關(guān)，針對不同的業(yè)務(wù)模型，定義需要的數(shù)據(jù)模型與實(shí)體類，以及相關(guān)的業(yè)務(wù)邏輯處理，雖然 Android 沒有明確定義 Model 層，但是我們在開發(fā)中都會(huì)定義一個(gè)專門的 model package 用來統(tǒng)一管理所有的 model 文件，如 User、Order、Chat 等。

這里做個(gè)補(bǔ)充，因?yàn)閷τ诓糠殖鯇W(xué)者可能不理解什么是 Model，Model 的具體職責(zé)以及什么是所謂的業(yè)務(wù)邏輯?這里姑且說明下：

1. Model 即模型，也就是數(shù)據(jù)模型，通常就是所謂的 JavaBean 實(shí)體類，比如在界面上我們要顯示一些用戶信息，這個(gè)時(shí)候我們必須定義一個(gè) User 對象，這個(gè) User 對象也即所謂的 Model，如

public class User { 
    private int age; 
    private String name; 
    private ... 
    public void setAge(int age) { 
    } 
    public int getAge() { 
        return age; 
    } 
    ... 
} 

通常這個(gè)就是 Model 的主要功能。

2. Model 就是一個(gè)數(shù)據(jù)模型的定義，定義了供我們使用的數(shù)據(jù)實(shí)體類而已。因?yàn)榇蟛糠治覀兊臄?shù)據(jù)來源都是來自后端，客戶端不需要處理太多的業(yè)務(wù)邏輯，所以大部分情況下 Model 也就只包含基本的屬性與 get、set 方法。但是，并不是說明客戶端不包含任何業(yè)務(wù)邏輯，比如我們除了顯示用戶的基本信息外還需要顯示用戶的身體質(zhì)量指數(shù)(也就是 BMI)，這個(gè)值不是一個(gè) Model 自帶的屬性，而是根據(jù)一些屬性通過一定的算法算出來的，這也就是所謂的業(yè)務(wù)邏輯。

BMI 的算法很簡單，就是體重(kg)÷ (身高^2(m))，有人可能直接在顯示的頁面把這段算法寫出來，比如直接在 Activity 有如下代碼：

textView.setText(String.valueOf(user.weight / (user.height * user.height))); 

這個(gè)當(dāng)然是可以，但是很糟糕，因?yàn)槟阈枰诿恳粋€(gè)顯示的地方都寫這么一段代碼，而它本身是屬于業(yè)務(wù)邏輯的，所以你應(yīng)該把這個(gè)算法放在 User 的 model 里處理：

public class User { 
    private int age; 
    private String name; 
    private float weight; 
    private float height; 
    ... 
    ... 
    public float getBMI() { 
        return weight / height * height; 
    } 
} 

然后只需要在需要顯示的地方調(diào)用 user.getBMI() 這個(gè)方法就 ok 了，這個(gè)算法其實(shí)就是所謂的簡單的業(yè)務(wù)邏輯。

當(dāng)然以上只是舉個(gè)例子，其實(shí)很簡單的概念，但是對于一些初學(xué)者可能不能理解，特此說明下，實(shí)際開發(fā)過程中，所有跟 model 相關(guān)的一些計(jì)算都可以算作業(yè)務(wù)邏輯，而這也是 Model 的第二個(gè)重要作用。

5.MVC 與三層架構(gòu)的關(guān)系

有人可能會(huì)問了，你一會(huì)三層架構(gòu)，一會(huì) MVC 的，他倆之間到底是什么關(guān)系?

三層架構(gòu)是一種軟件領(lǐng)域最普遍的分層式架構(gòu)，而 MVC 是在三層架構(gòu)的基礎(chǔ)上設(shè)計(jì)的一種框架型架構(gòu)，三層架構(gòu)是一種宏觀的概念，而 MVC 就是一種比較具體的三層架構(gòu)的框架實(shí)現(xiàn)，我們在 MVC 的基礎(chǔ)上把不同類別的代碼文件進(jìn)行分類就可以了，所以他們之間的關(guān)系可以用下圖來表示：

上圖可以看到，View 層和 Controller 層都屬于三層架構(gòu)的表示層，而 Model 層屬于業(yè)務(wù)層，有人又問了，那數(shù)據(jù)訪問層怎么沒有相對應(yīng)的呢?這個(gè)就是有爭議的地方了。

有人認(rèn)為 Model 層除了定義業(yè)務(wù)需要的實(shí)體類與簡單的邏輯算法處理之外，還應(yīng)該包括對數(shù)據(jù)庫的操作、對網(wǎng)絡(luò)等的操作等，這對后端開發(fā)來說沒問題，因?yàn)楹蠖说臄?shù)據(jù)全部來源于數(shù)據(jù)庫，而且后端可以很方便的跟數(shù)據(jù)服務(wù)器進(jìn)行連接，而 Model 的業(yè)務(wù)邏輯大多都是來自對數(shù)據(jù)的處理，所以這種方式很正常。

但是對于客戶端來說差別就大了，我們知道客戶端的數(shù)據(jù)來源大多來自服務(wù)端的接口請求，但是很可能同時(shí)有本地?cái)?shù)據(jù)庫、本地的文件都能提供數(shù)據(jù)，比如可能會(huì)有離線操作，比如可能為了用戶體驗(yàn)，用戶斷網(wǎng)的時(shí)候會(huì)做緩存處理，也就是說客戶端的數(shù)據(jù)來源有多種多樣，而 Model 本身的主要職責(zé)應(yīng)該定義業(yè)務(wù)需要的數(shù)據(jù)模型以及簡單的邏輯處理，如果同時(shí)也要處理本地?cái)?shù)據(jù)庫與網(wǎng)絡(luò)數(shù)據(jù)未免變得臃腫起來，而且職責(zé)不清晰。

所以，我是非常不建議在 Model 層做多余的數(shù)據(jù)處理工作的，而對應(yīng)三層架構(gòu)我強(qiáng)烈建議客戶端的開發(fā)中應(yīng)該多一層 data 層，也就是所謂的數(shù)據(jù)處理層，這一層包含了對 database、network、sharedpreference 等數(shù)據(jù)的處理，Model 層回歸最簡單、最本質(zhì)的模型職責(zé)，只定義業(yè)務(wù)需要的數(shù)據(jù)模型與簡單的邏輯處理即可。

6.MVC 的優(yōu)缺點(diǎn)

雖然 Android 開發(fā)框架并不是嚴(yán)格意義上的 MVC，但是顯而易見，默認(rèn)的開發(fā)就是 MVC 框架，優(yōu)點(diǎn)也很明顯，學(xué)習(xí)成本很低，理解很容易，對 UI 層與業(yè)務(wù)層做了分離，我們只需要對 Model 層與 data 層做個(gè)簡單的分層與封裝，就是一個(gè)擴(kuò)展性還不錯(cuò)、還算清晰的開發(fā)架構(gòu)。

但是缺點(diǎn)也很明顯，隨著功能的不斷迭代與越來越復(fù)雜的交互處理，Controller 層也就是 Activity、Fragment 中的代碼越來越多，變得很臃腫，難以維護(hù)，尤其在需求變化的時(shí)候，改起來特別痛苦，我甚至見過一個(gè) Activity 有幾千行代碼的情況，試想這得多痛苦，當(dāng)然出現(xiàn)這種情況本身也有程序員自己的問題，但是這暴露了 MVC 這種架構(gòu)的缺點(diǎn)。

MVC 可以說是最經(jīng)典的架構(gòu)模式，它適用于大部分的開發(fā)場景，如果你對架構(gòu)不怎么了解，那么建議老老實(shí)實(shí)的使用 MVC，在此架構(gòu)基礎(chǔ)上進(jìn)行封裝與優(yōu)化絕對夠了，只是項(xiàng)目到了一定體量了，需求也越來越復(fù)雜，總歸是會(huì)碰到難以擴(kuò)展、Controller 層發(fā)展成“死胖子”的情況，這個(gè)時(shí)候怎么解決呢?且聽下回分解，當(dāng)然下篇什么時(shí)候我也不清楚。

【本文為51CTO專欄作者“stormzhang”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者(微信號(hào)：googdev)】