建站
咨詢
售后
建站咨詢
新聞中心
很多人表示對(duì)架構(gòu)沒(méi)有任何概念，想了解下架構(gòu)，但是看了網(wǎng)上的一些文章又覺(jué)得云里霧里，其實(shí)架構(gòu)遠(yuǎn)沒(méi)有那么難，今天從這篇文章開(kāi)始我來(lái)給大家談?wù)劶軜?gòu)，爭(zhēng)取讓大家都看得懂。
創(chuàng)新互聯(lián)建站公司2013年成立，先為弓長(zhǎng)嶺等服務(wù)建站，弓長(zhǎng)嶺等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為弓長(zhǎng)嶺企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
1.什么是架構(gòu)?
對(duì)于架構(gòu)，業(yè)界從來(lái)沒(méi)有一個(gè)統(tǒng)一的定義，架構(gòu)一詞最初來(lái)自建筑業(yè)，假如我們要蓋一棟大樓，那在完成這么一項(xiàng)重大工程之前肯定需要建造師的建筑圖紙，而這建筑圖紙可以說(shuō)是建筑業(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è)字聽(tīng)起來(lái)有點(diǎn)難以理解，其實(shí)通俗來(lái)講就是單一職責(zé)的功能封裝成模塊，在模塊內(nèi)部高度聚合，模塊與模塊之間不會(huì)互相依賴，即低耦合。比如我們常用的網(wǎng)絡(luò)庫(kù)、圖片加載庫(kù)，這都是屬于兩個(gè)模塊，在每個(gè)模塊內(nèi)部功能單一，代碼高度內(nèi)聚，但是網(wǎng)絡(luò)庫(kù)與圖片加載庫(kù)又不互相依賴，都可以獨(dú)立工作，互不干擾，這就是所謂的低耦合。
而我們追求「高內(nèi)聚，低耦合」的目的很簡(jiǎn)單，我們想讓開(kāi)發(fā)人員只專注于一點(diǎn)，提高開(kāi)發(fā)效率的同時(shí)，也對(duì)代碼的健壯性與擴(kuò)展性有很大好處。試想，如果你做的功能需要同時(shí)跟四個(gè)部門(mén)進(jìn)行合作，依賴于他們的模塊，那么你的開(kāi)發(fā)效率肯定奇低，而且依賴過(guò)高，其他部門(mén)的代碼稍一改動(dòng)很可能就會(huì)對(duì)你產(chǎn)生影響，而且問(wèn)題還不容易定位，這將是一個(gè)定時(shí)炸彈。
所以，架構(gòu)的重要性不言而喻，但是架構(gòu)有一條原則：千萬(wàn)不要過(guò)度設(shè)計(jì)!
如果你蓋的是棟大樓，你肯定需要建造師的建筑圖紙，但是如果你蓋的是一間茅草屋，你覺(jué)得你還需要請(qǐng)個(gè)建造師來(lái)先給你設(shè)計(jì)一張建筑圖紙?jiān)匍_(kāi)工么?可能花在設(shè)計(jì)建筑圖紙的時(shí)間都?jí)蚰闵w完了。所以架構(gòu)一定得看不同場(chǎng)景的需求，如果你的工程總共就十來(lái)個(gè)文件，那么你在開(kāi)發(fā)的過(guò)程中運(yùn)用各種設(shè)計(jì)模式、考慮各種分層，只會(huì)讓原本簡(jiǎn)單的東西復(fù)雜化，還會(huì)增加工作量，這違背了架構(gòu)的初衷。
最原始、最簡(jiǎn)單的東西反而是最高效的，只不過(guò)我們的項(xiàng)目慢慢變得龐大，那些最原始的框架與結(jié)構(gòu)滿足不了我們的需求了，這個(gè)時(shí)候我們必須從整體出發(fā)重新考慮整個(gè)項(xiàng)目的架構(gòu)，通過(guò)架構(gòu)來(lái)幫助我們提高生產(chǎn)力，減少重復(fù)繁雜的工作量，提升工作效率。
2.三層架構(gòu)
說(shuō)到架構(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ù)訪問(wèn)層。
我們拿訪問(wèn)一個(gè)網(wǎng)站來(lái)舉個(gè)例子。你在瀏覽器輸入一個(gè)網(wǎng)址，訪問(wèn)一個(gè)網(wǎng)站的時(shí)候，這中間經(jīng)過(guò)了這么一個(gè)過(guò)程，用戶在瀏覽器輸入 url，然后瀏覽器向 Server 發(fā)起一個(gè) http 請(qǐng)求，Server 拿到這個(gè) http 請(qǐng)求之后會(huì)根據(jù)相關(guān)的條件到數(shù)據(jù)庫(kù)查詢相關(guān)數(shù)據(jù)，然后把數(shù)據(jù)以特定的格式(網(wǎng)站是 html 格式)返回給瀏覽器，瀏覽器再根據(jù)特定數(shù)據(jù)渲染出相應(yīng)頁(yè)面。
這其中就對(duì)應(yīng)了三層架構(gòu)，首先對(duì)用戶來(lái)說(shuō)，瀏覽器就是表示層，它主要是與用戶交互的頁(yè)面，根據(jù)用戶的輸入與事件，處理并顯示返回的特定數(shù)據(jù)。我們知道數(shù)據(jù)是一切應(yīng)用程序的基礎(chǔ)，如果沒(méi)有數(shù)據(jù)，那么沒(méi)有任何意義，所以 Server 端必須要一個(gè)強(qiáng)大的數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)所有用戶交互產(chǎn)生的數(shù)據(jù)，而對(duì)這些數(shù)據(jù)的處理，包括增、刪、改、查就屬于數(shù)據(jù)訪問(wèn)層。那么連接表示層與數(shù)據(jù)訪問(wèn)層的就是業(yè)務(wù)邏輯層，這包括后端程序中模型設(shè)計(jì)、驗(yàn)證、業(yè)務(wù)規(guī)則、各種計(jì)算等。
所以后端的架構(gòu)是很復(fù)雜的，它除了有復(fù)雜的業(yè)務(wù)邏輯之外，還有存儲(chǔ)、性能、并發(fā)、負(fù)載均衡等等，所以架構(gòu)師一職最初也是針對(duì)服務(wù)端提供的職位。
3.MVC
隨著移動(dòng)端的普及，手機(jī)端的應(yīng)用程序功能越來(lái)越大，項(xiàng)目也越來(lái)越復(fù)雜，所以移動(dòng)端架構(gòu)也被越來(lái)越多的人關(guān)注與重視，但是移動(dòng)端架構(gòu)遠(yuǎn)沒(méi)有服務(wù)端復(fù)雜，一是移動(dòng)端的數(shù)據(jù)來(lái)源于服務(wù)端，不必有專門(mén)的數(shù)據(jù)存儲(chǔ)，最多有本地的緩存以及一些必要的小型數(shù)據(jù)庫(kù)，對(duì)于一些復(fù)雜的業(yè)務(wù)邏輯也更多的放在服務(wù)端，而且客戶端不必考慮成百上千萬(wàn)用戶的同時(shí)訪問(wèn)，移動(dòng)端通常更應(yīng)該把精力專注在 UI、交互、體驗(yàn)上，所以客戶端的架構(gòu)沒(méi)有那么重，但是為了讓移動(dòng)端代碼分層更加清晰，代碼擴(kuò)展性更好，以及更好的高內(nèi)聚、低耦合，目前有一系列的移動(dòng)端架構(gòu)方案，大家耳熟能詳?shù)谋热?MVC、MVP、MVVM、Clean 等，今天就先來(lái)針對(duì) Android 開(kāi)發(fā)，來(lái)講講 MVC 的概念。
MVC 是 Model(模型)、View(視圖)、Controller(控制器) 的縮寫(xiě)，其中 View 層處理界面顯示，Controller 層用來(lái)處理用戶的交互與事件，Model 層則用來(lái)定義實(shí)體對(duì)象與處理業(yè)務(wù)邏輯。
這么說(shuō)難免有點(diǎn)晦澀難懂，我們來(lái)拿我們最熟悉的 Android 開(kāi)發(fā)來(lái)舉例。
4.Android MVC
其實(shí) Android 開(kāi)發(fā)本身默認(rèn)的就是一套 MVC 實(shí)現(xiàn)。
View 層：Android 開(kāi)發(fā)中的 xml 布局就是我們的 View 層，默認(rèn)情況下也建議 View 都盡量用 xml 實(shí)現(xiàn)，當(dāng)然對(duì)于一些復(fù)雜的就需要我們自定義 View 了，自定義 View 同樣也是屬于 View 層，只不過(guò)大多數(shù)時(shí)候還是 xml 布局用的最多;
Controller 層：毫無(wú)疑問(wèn)，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 正確的顯示出來(lái)，而這都是 Activity & Fragment 的工作。
Model 層：Android 中對(duì) View 與 Controller 有了定義，其實(shí)沒(méi)有對(duì) Model 層做定義，而大部分架構(gòu)都不會(huì)對(duì) Model 層做定義，因?yàn)?Model 本身是跟業(yè)務(wù)相關(guān)，針對(duì)不同的業(yè)務(wù)模型，定義需要的數(shù)據(jù)模型與實(shí)體類，以及相關(guān)的業(yè)務(wù)邏輯處理，雖然 Android 沒(méi)有明確定義 Model 層，但是我們?cè)陂_(kāi)發(fā)中都會(huì)定義一個(gè)專門(mén)的 model package 用來(lái)統(tǒng)一管理所有的 model 文件，如 User、Order、Chat 等。
這里做個(gè)補(bǔ)充，因?yàn)閷?duì)于部分初學(xué)者可能不理解什么是 Model，Model 的具體職責(zé)以及什么是所謂的業(yè)務(wù)邏輯?這里姑且說(shuō)明下：
1. Model 即模型，也就是數(shù)據(jù)模型，通常就是所謂的 JavaBean 實(shí)體類，比如在界面上我們要顯示一些用戶信息，這個(gè)時(shí)候我們必須定義一個(gè) User 對(duì)象，這個(gè) User 對(duì)象也即所謂的 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ù)來(lái)源都是來(lái)自后端，客戶端不需要處理太多的業(yè)務(wù)邏輯，所以大部分情況下 Model 也就只包含基本的屬性與 get、set 方法。但是，并不是說(shuō)明客戶端不包含任何業(yè)務(wù)邏輯，比如我們除了顯示用戶的基本信息外還需要顯示用戶的身體質(zhì)量指數(shù)(也就是 BMI)，這個(gè)值不是一個(gè) Model 自帶的屬性，而是根據(jù)一些屬性通過(guò)一定的算法算出來(lái)的，這也就是所謂的業(yè)務(wù)邏輯。
BMI 的算法很簡(jiǎn)單，就是體重(kg)÷ (身高^(guò)2(m))，有人可能直接在顯示的頁(yè)面把這段算法寫(xiě)出來(lái)，比如直接在 Activity 有如下代碼：
- textView.setText(String.valueOf(user.weight / (user.height * user.height)));
這個(gè)當(dāng)然是可以，但是很糟糕，因?yàn)槟阈枰诿恳粋€(gè)顯示的地方都寫(xiě)這么一段代碼，而它本身是屬于業(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í)就是所謂的簡(jiǎn)單的業(yè)務(wù)邏輯。
當(dāng)然以上只是舉個(gè)例子，其實(shí)很簡(jiǎn)單的概念，但是對(duì)于一些初學(xué)者可能不能理解，特此說(shuō)明下，實(shí)際開(kāi)發(fā)過(guò)程中，所有跟 model 相關(guān)的一些計(jì)算都可以算作業(yè)務(wù)邏輯，而這也是 Model 的第二個(gè)重要作用。
5.MVC 與三層架構(gòu)的關(guān)系
有人可能會(huì)問(wèn)了，你一會(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)，我們?cè)?MVC 的基礎(chǔ)上把不同類別的代碼文件進(jìn)行分類就可以了，所以他們之間的關(guān)系可以用下圖來(lái)表示：
上圖可以看到，View 層和 Controller 層都屬于三層架構(gòu)的表示層，而 Model 層屬于業(yè)務(wù)層，有人又問(wèn)了，那數(shù)據(jù)訪問(wèn)層怎么沒(méi)有相對(duì)應(yīng)的呢?這個(gè)就是有爭(zhēng)議的地方了。
有人認(rèn)為 Model 層除了定義業(yè)務(wù)需要的實(shí)體類與簡(jiǎn)單的邏輯算法處理之外，還應(yīng)該包括對(duì)數(shù)據(jù)庫(kù)的操作、對(duì)網(wǎng)絡(luò)等的操作等，這對(duì)后端開(kāi)發(fā)來(lái)說(shuō)沒(méi)問(wèn)題，因?yàn)楹蠖说臄?shù)據(jù)全部來(lái)源于數(shù)據(jù)庫(kù)，而且后端可以很方便的跟數(shù)據(jù)服務(wù)器進(jìn)行連接，而 Model 的業(yè)務(wù)邏輯大多都是來(lái)自對(duì)數(shù)據(jù)的處理，所以這種方式很正常。
但是對(duì)于客戶端來(lái)說(shuō)差別就大了，我們知道客戶端的數(shù)據(jù)來(lái)源大多來(lái)自服務(wù)端的接口請(qǐng)求，但是很可能同時(shí)有本地?cái)?shù)據(jù)庫(kù)、本地的文件都能提供數(shù)據(jù)，比如可能會(huì)有離線操作，比如可能為了用戶體驗(yàn)，用戶斷網(wǎng)的時(shí)候會(huì)做緩存處理，也就是說(shuō)客戶端的數(shù)據(jù)來(lái)源有多種多樣，而 Model 本身的主要職責(zé)應(yīng)該定義業(yè)務(wù)需要的數(shù)據(jù)模型以及簡(jiǎn)單的邏輯處理，如果同時(shí)也要處理本地?cái)?shù)據(jù)庫(kù)與網(wǎng)絡(luò)數(shù)據(jù)未免變得臃腫起來(lái)，而且職責(zé)不清晰。
所以，我是非常不建議在 Model 層做多余的數(shù)據(jù)處理工作的，而對(duì)應(yīng)三層架構(gòu)我強(qiáng)烈建議客戶端的開(kāi)發(fā)中應(yīng)該多一層 data 層，也就是所謂的數(shù)據(jù)處理層，這一層包含了對(duì) database、network、sharedpreference 等數(shù)據(jù)的處理，Model 層回歸最簡(jiǎn)單、最本質(zhì)的模型職責(zé)，只定義業(yè)務(wù)需要的數(shù)據(jù)模型與簡(jiǎn)單的邏輯處理即可。
6.MVC 的優(yōu)缺點(diǎn)
雖然 Android 開(kāi)發(fā)框架并不是嚴(yán)格意義上的 MVC，但是顯而易見(jiàn)，默認(rèn)的開(kāi)發(fā)就是 MVC 框架，優(yōu)點(diǎn)也很明顯，學(xué)習(xí)成本很低，理解很容易，對(duì) UI 層與業(yè)務(wù)層做了分離，我們只需要對(duì) Model 層與 data 層做個(gè)簡(jiǎn)單的分層與封裝，就是一個(gè)擴(kuò)展性還不錯(cuò)、還算清晰的開(kāi)發(fā)架構(gòu)。
但是缺點(diǎn)也很明顯，隨著功能的不斷迭代與越來(lái)越復(fù)雜的交互處理，Controller 層也就是 Activity、Fragment 中的代碼越來(lái)越多，變得很臃腫，難以維護(hù)，尤其在需求變化的時(shí)候，改起來(lái)特別痛苦，我甚至見(jiàn)過(guò)一個(gè) Activity 有幾千行代碼的情況，試想這得多痛苦，當(dāng)然出現(xiàn)這種情況本身也有程序員自己的問(wèn)題，但是這暴露了 MVC 這種架構(gòu)的缺點(diǎn)。
MVC 可以說(shuō)是最經(jīng)典的架構(gòu)模式，它適用于大部分的開(kāi)發(fā)場(chǎng)景，如果你對(duì)架構(gòu)不怎么了解，那么建議老老實(shí)實(shí)的使用 MVC，在此架構(gòu)基礎(chǔ)上進(jìn)行封裝與優(yōu)化絕對(duì)夠了，只是項(xiàng)目到了一定體量了，需求也越來(lái)越復(fù)雜，總歸是會(huì)碰到難以擴(kuò)展、Controller 層發(fā)展成“死胖子”的情況，這個(gè)時(shí)候怎么解決呢?且聽(tīng)下回分解，當(dāng)然下篇什么時(shí)候我也不清楚。
【本文為專欄作者“stormzhang”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者(微信號(hào)：googdev)】
當(dāng)前標(biāo)題：架構(gòu)淺談之MVC
網(wǎng)站地址：http://www.dlmjj.cn/article/dghhshe.html
