建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
互聯(lián)網(wǎng)分層架構(gòu)演進(jìn)有兩條核心原則：
目前成都創(chuàng)新互聯(lián)公司已為上1000家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計(jì)、夷陵網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶(hù)導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶(hù)和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
- 讓上游更高效的獲取與處理數(shù)據(jù)(復(fù)用);
- 讓下游能屏蔽數(shù)據(jù)的獲取細(xì)節(jié)(封裝);
數(shù)據(jù)從數(shù)據(jù)庫(kù)/緩存層，到微服務(wù)層，到站點(diǎn)應(yīng)用層，最終都匯聚到客戶(hù)端。服務(wù)端的分層架構(gòu)設(shè)計(jì)已經(jīng)講了很多，客戶(hù)端的分層架構(gòu)設(shè)計(jì)應(yīng)該怎么玩呢，服務(wù)端的分層架構(gòu)設(shè)計(jì)是否有能夠借鑒的地方呢，今天和大家簡(jiǎn)單聊一聊。
先來(lái)看小詩(shī)一首：
《Android猿》
曾經(jīng)
所有代碼
都被寫(xiě)在Activity里
幾乎
沒(méi)有代碼
可以復(fù)用
每當(dāng)
看到Activity里
2000行的函數(shù)
我就
想要離職
上面，是團(tuán)隊(duì)中一個(gè)文藝Android程序員的自述，表達(dá)的核心觀(guān)點(diǎn)是：幾乎所有代碼都寫(xiě)在了Activity里(不理解Activity的，暫且認(rèn)為是MVC里的view層)，完全沒(méi)有封裝和復(fù)用。
假設(shè)一個(gè)具體的例子，微信登錄的界面，點(diǎn)擊登錄按鈕，此時(shí)可能要執(zhí)行：
- 驗(yàn)證用戶(hù)名密碼;
- 拉取好友列表;
- 拉取用戶(hù)信息;
- 拉取好友信息;
- 拉取離線(xiàn)消息;
- ...
畫(huà)外音：那個(gè)大月亮的畫(huà)面，要卡很久。
如果把這些都寫(xiě)在微信“登錄Activity”里，會(huì)發(fā)現(xiàn)一些很?chē)?yán)重的問(wèn)題：
- 登錄整個(gè)邏輯不能復(fù)用;
- 登錄過(guò)程中的每個(gè)子邏輯也無(wú)法復(fù)用;
假設(shè)產(chǎn)品里有一個(gè)“離線(xiàn)后重新登錄”的功能，步驟與登錄相同，就需要把上述在“重新登錄Activity”里代碼復(fù)制一遍。
又假設(shè)產(chǎn)品里有一個(gè)地方需要“拉取用戶(hù)信息”，也將把“登錄Activity”里“拉取用戶(hù)信息”的代碼復(fù)制一遍。
封裝復(fù)用的道理誰(shuí)都懂，拷貝代碼的壞處也誰(shuí)都明白，那為什么大家還這么做，代碼越來(lái)越“腐爛”呢?
根據(jù)個(gè)人經(jīng)驗(yàn)，主要是這么幾點(diǎn)原因：
(1)早期業(yè)務(wù)壓力大，APP是少數(shù)幾個(gè)同學(xué)的，沒(méi)有提前做規(guī)劃;
(2)后期代碼越來(lái)越臃腫，不敢動(dòng)，一動(dòng)怕影響功能，怕出問(wèn)題，怕?lián)?zé)任;
(3)項(xiàng)目中，是以功能界面進(jìn)行編碼劃分的，一個(gè)同學(xué)會(huì)同時(shí)負(fù)責(zé)MVC三部分編碼，加之項(xiàng)目壓力又大，既然是一個(gè)人寫(xiě)，就沒(méi)必要分層了，搞多了調(diào)用反而麻煩;
(4)項(xiàng)目中，有個(gè)需求好像之前做過(guò)，代碼一看，寫(xiě)在Activity里，糾結(jié)。抽象成函數(shù)?還得改別人的代碼，算了，還是拷貝一份吧;
(5)…
不管歷史原因，項(xiàng)目原因，個(gè)人的原因，大家都知道分層抽象，代碼復(fù)用是正確的，那有什么方案能夠?qū)⑦@個(gè)分層抽象落地，從后端的分層架構(gòu)中是否有可借鑒的地方呢?
一個(gè)典型業(yè)務(wù)系統(tǒng)的后端架構(gòu)如上：
- web-server層調(diào)用RPC接口，從service層獲取數(shù)據(jù)，拼裝html/json，完成數(shù)據(jù)展現(xiàn);
- biz-service/data-service向上游提供可復(fù)用的原子接口，實(shí)現(xiàn)業(yè)務(wù)邏輯，并通過(guò)DAO層，從db層獲取數(shù)據(jù);
- db層提供數(shù)據(jù);
APP端的分層架構(gòu)不是非常相似么?
還是以登錄業(yè)務(wù)為例：
(1)登錄Activity有兩個(gè)按鈕，一個(gè)確認(rèn)按鈕，一個(gè)取消按鈕，這兩個(gè)按鈕的點(diǎn)擊，分別只能調(diào)用一個(gè)函數(shù)：
- on_LoginConfirm_Click
- on_LoginCancel_Click
這里相當(dāng)于展現(xiàn)層，除了交互與展現(xiàn)，View層只能調(diào)用這兩個(gè)函數(shù)。
(2)這兩個(gè)函數(shù)的實(shí)現(xiàn)，是通過(guò)若干可復(fù)用的“原子業(yè)務(wù)邏輯”函數(shù)實(shí)現(xiàn)的：
- 驗(yàn)證用戶(hù)名密碼：bool verifyPass(name, pass)
- 拉取好友列表：List getFriendList(uid)
- 拉取用戶(hù)信息：Use rgetUserInfo(uid)
- 拉取好友信息：List getUserInfo(List )
- 拉取離線(xiàn)消息：List getOfflineMst(uid)
這相當(dāng)于服務(wù)層，實(shí)現(xiàn)業(yè)務(wù)邏輯，提供封裝和復(fù)用
(3)“原子業(yè)務(wù)邏輯”函數(shù)執(zhí)行的過(guò)程中，需要訪(fǎng)問(wèn)數(shù)據(jù)，數(shù)據(jù)的獲取又分為兩類(lèi)：
- 同步獲取：通過(guò)文件，內(nèi)存，本地?cái)?shù)據(jù)庫(kù)獲取
- 異步獲?。簭膕erver獲取，往往通過(guò)回調(diào)實(shí)現(xiàn)
這里相當(dāng)于數(shù)據(jù)層，向上游屏蔽數(shù)據(jù)獲取的復(fù)雜性，分別用不同的Proxy去實(shí)現(xiàn)。
在這種結(jié)構(gòu)下：
(1)展現(xiàn)層非常輕，只調(diào)用一個(gè)函數(shù)，用于展現(xiàn)數(shù)據(jù);
(2)“原子業(yè)務(wù)邏輯”可以復(fù)用，不同的展現(xiàn)層Activity可以隨意組合，實(shí)現(xiàn)不同的業(yè)務(wù)邏輯，用于處理數(shù)據(jù);
(3)Proxy對(duì)上游屏蔽的數(shù)據(jù)獲取的復(fù)雜性，向上游提供數(shù)據(jù)獲取接口，用于獲取數(shù)據(jù);
分層架構(gòu)封裝復(fù)用的思想，前后端有共通的地方。
Activity里一坨坨復(fù)雜的代碼，也是你曾經(jīng)的痛么?
【本文為專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
戳這里，看該作者更多好文
文章標(biāo)題：你的業(yè)務(wù)代碼，是不是都寫(xiě)在了Activity里？
本文鏈接：http://www.5511xx.com/article/djdpdpc.html
