mvp的全称_是让人提神醒脑的 MVP、MVVM 关系精讲!
前言
很高興見(jiàn)到你!
我是《Jetpack MVVM 精講》的獨(dú)立原創(chuàng)作者 KunMinX,GitHub star 8.7k,專注于深度思考和 Jetpack MVVM 的分享。
關(guān)于 MVP 和 MVVM 本質(zhì)和區(qū)別的文章,本來(lái)我是不想寫(xiě)的,因?yàn)榻?jīng)過(guò)長(zhǎng)達(dá)一年的耳濡目染 和對(duì)方法論的試煉,相信 但凡沉下心閱讀過(guò)《重學(xué)安卓》體系化文章的讀者,多已練就 透過(guò)表象迅速抓住本質(zhì) 的稀缺能力。
專欄每天都有新的讀者加入,然而沒(méi)想到的是,1 年了,仍然時(shí)不時(shí)的會(huì)被咨詢、或是在各個(gè)社區(qū)看到人們眾說(shuō)紛紜地在談?wù)?MVP 和 MVVM 誰(shuí)“好”誰(shuí)“壞”。
并不是每一個(gè)提問(wèn)都值得被回答
愛(ài)因斯坦說(shuō),“提出正確的問(wèn)題,問(wèn)題就已解決了一半”。
換言之,并不是每一個(gè)提問(wèn)都值得被回答。一次提問(wèn)所包含的信息量,其實(shí)遠(yuǎn)遠(yuǎn)超出內(nèi)容本身。
透過(guò)提問(wèn)者的提問(wèn),幾乎可以瞬間感知到,提問(wèn)者對(duì)事實(shí)狀況的掌握程度,并由此來(lái)決定到底值不值得繼續(xù)交流。
與“高”質(zhì)量提問(wèn)者的交流 讓人感到如沐春風(fēng) —— 幾句話就能自己先把背景交代清楚,然后就某個(gè)細(xì)節(jié)提出自己的困惑 —— 這讓我不免想要與之多聊幾句,把我知道的毫無(wú)保留地分享出去。
反之,“低”質(zhì)量提問(wèn) 讓人感到 不舒服,甚至不對(duì)勁 —— 明明不遺余力地在多處 劃重點(diǎn) 反復(fù)交代,明明白紙黑字寫(xiě)得清清楚楚,甚至段落、鏈接給他指出來(lái),卻視而不見(jiàn),就好像從未發(fā)生過(guò)。
注:我從不在技術(shù)交流中使用 “高”、“低”、“好”、“壞”、“輕”、“重” 之類的主觀描述,此處只是以多數(shù)人方便理解的方式來(lái)介紹。文中使用到的主觀描述一律加上雙引號(hào)。
更有甚者,為了滿足抬杠的快感,不惜浪費(fèi)彼此的時(shí)間 ? ... ?
本質(zhì)和區(qū)別,我只說(shuō)一遍
事實(shí)上,我并不會(huì)去判斷來(lái)者是否是來(lái)抬杠,而只須透過(guò)對(duì)方所說(shuō)的話,即可瞬間判斷對(duì)方說(shuō)的是事實(shí),還是自顧自地扯淡 —— 你沒(méi)法和一個(gè)前來(lái)扯淡的人交流,你會(huì)發(fā)現(xiàn) 這種對(duì)話往往 存在巨大的代溝,并且抬杠者無(wú)意謀求和縫合對(duì)事實(shí)的理解,他本來(lái)就是為了 “來(lái)的快” 的精神勝利而來(lái)。
事實(shí)即 "就事論事",事實(shí)必有特定背景和目的來(lái)約束。一切脫離事實(shí)特征的意見(jiàn)和觀點(diǎn)都是瞎扯淡,沒(méi)有討論的前提、不值得參與 —— ?KunMinX
所以,本文只寫(xiě)給那些 真的想搞清楚事實(shí) 的有緣人,只為有緣人鋪路。
并且關(guān)于 MVP 和 MVVM 各自的本質(zhì)及區(qū)別,我就只說(shuō)這么一遍,所以請(qǐng)認(rèn)真閱讀。
文章目錄一覽
前言
并不是每一個(gè)提問(wèn)都值得被回答
本質(zhì)和區(qū)別,我只說(shuō)一遍
先說(shuō)結(jié)論
所以二者的區(qū)別是什么?
Jetpack MVVM 和 MVVM 模式的關(guān)系
我為什么能瞬間感知溝通質(zhì)量的 “好” 與 “壞” ?
綜上
先說(shuō)結(jié)論
MVP 本質(zhì):是廣義上的架構(gòu)模式,適用于面向?qū)嶓w或虛擬用戶接口的開(kāi)發(fā)。
它主要是在 MVC 的背景下,通過(guò) 依賴倒置,來(lái)解決 邏輯復(fù)用 難、實(shí)現(xiàn)更替 難 的問(wèn)題。
MVVM 本質(zhì):是狹義上的架構(gòu)模式,專用于頁(yè)面開(kāi)發(fā)。
它主要是在多人協(xié)作的軟件工程的背景下,通過(guò)只操作 ViewModel 中映射的視圖數(shù)據(jù) 來(lái)刷新視圖狀態(tài),以此來(lái)解決 視圖調(diào)用的一致性問(wèn)題 從而規(guī)避不可預(yù)期的錯(cuò)誤。
所以二者的區(qū)別是什么?
區(qū)別就在于:
一個(gè)是廣義上的架構(gòu):
你可以通過(guò)同一套邏輯去驅(qū)動(dòng)不同品牌設(shè)備的實(shí)體用戶接口(比如不同品牌的耳機(jī)線控),或虛擬用戶接口(比如 Android 視圖,但存在一致性問(wèn)題而不推薦);
一個(gè)是狹義上的架構(gòu):
專用于可視化頁(yè)面的開(kāi)發(fā),通過(guò)解決一致性問(wèn)題 來(lái)規(guī)避不可預(yù)期的錯(cuò)誤。
所以輕易地你就可發(fā)現(xiàn),二者分別適用于 在各自的專場(chǎng)下 解決不同的問(wèn)題,根本沒(méi)有可比性,更沒(méi)有所謂的 誰(shuí)“好”誰(shuí)“壞” 之分。
而且除了沒(méi)有可比性,二者之間其實(shí)也沒(méi)任何關(guān)系,MVP 的特質(zhì)是 依賴倒置,MVVM 的特質(zhì)是 數(shù)據(jù)驅(qū)動(dòng),二者沒(méi)有說(shuō)誰(shuí)演化自誰(shuí)的關(guān)系?;氐絼倓偹f(shuō)的:“根本就是 特定場(chǎng)景下解決特定問(wèn)題 的兩種截然不同的架構(gòu)模式”。
沒(méi)有所謂的 MVVM == MVP + DataBinding,沒(méi)有的。
Jetpack MVVM 和 MVVM 模式的關(guān)系
Jetpack MVVM 是 MVVM 模式在 Android 開(kāi)發(fā)中的一個(gè)具體落實(shí),也即它不僅僅包含了 MVVM 模式用于解決 “視圖調(diào)用的一致性問(wèn)題” 這一本質(zhì),還兼顧了 Android 頁(yè)面開(kāi)發(fā)中其他不可預(yù)期的錯(cuò)誤。
正如我在《 Jetpack MVVM 精講》中介紹到的:
Lifecycle 的存在,主要是為了解決 生命周期管理 的一致性問(wèn)題。
LiveData 的存在,主要是為了幫助 新手老手 都能不假思索地 遵循 通過(guò)唯一可信源分發(fā)狀態(tài) 的標(biāo)準(zhǔn)化開(kāi)發(fā)理念,從而在快速開(kāi)發(fā)過(guò)程中 規(guī)避一系列 難以追溯、難以排查、不可預(yù)期 的問(wèn)題。
ViewModel 的存在,主要是為了解決 狀態(tài)管理 和 頁(yè)面通信 的問(wèn)題。
DataBinding 的存在,主要是為了解決 視圖調(diào)用 的一致性問(wèn)題。
它們的存在 大都是為了 在軟件工程的背景下 解決一致性的問(wèn)題、將容易出錯(cuò)的操作在后臺(tái)封裝好,方便使用者快速、穩(wěn)定、不產(chǎn)生預(yù)期外錯(cuò)誤地編碼。
所以,Jetpack MVVM 的高頻核心架構(gòu)組件,和 iOS、WPF 的實(shí)現(xiàn)一定是有區(qū)別的,只不過(guò)抓住本質(zhì),我們就能舉一反三,以不變應(yīng)萬(wàn)變。
通過(guò)《事關(guān)軟件工程安全 的 數(shù)據(jù)驅(qū)動(dòng) UI 框架 掃盲干貨》一文的介紹我們可知,DataBinding 的唯一挑戰(zhàn)者是 基于函數(shù)式編程的數(shù)據(jù)驅(qū)動(dòng) UI 框架,也即發(fā)源自前端 Elm 框架的 React、Flutter、Jetpack Compose、SwiftUI 之流。
所以 React、Flutter 這種,算不算 MVVM 呢?其實(shí)也算。DataBinding 被換下了,但視圖調(diào)用一致性問(wèn)題有函數(shù)式編程來(lái)解決。
所以 ...
我為什么能瞬間感知溝通質(zhì)量的 “好” 與 “壞” ?
事實(shí)上,在 “先說(shuō)結(jié)論” 一節(jié)介紹完本質(zhì)后,按照慣例,我是會(huì)以 “如果這樣說(shuō)還沒(méi)有理解的話” 來(lái)引出下文,開(kāi)始交代 “Before” 和 “After” 的,
因?yàn)槊刻於加行碌淖x者加入,為方便新讀者能夠 結(jié)合自己的興趣 隨機(jī)閱讀,專欄幾乎每一篇文章 都是以獨(dú)立專輯的完整度來(lái)發(fā)行。
這也是為什么,我的每一篇文章,都當(dāng)做自己是第一次和讀者見(jiàn)面、不遺余力地貫徹 全網(wǎng)獨(dú)家的深度思考寫(xiě)作風(fēng)格,讓每一位新讀者都有機(jī)會(huì)和我注入到文章的靈魂發(fā)生交流。
然而這一次,我不得不小小地任性一把,因?yàn)槿绻鲜鲞@樣說(shuō)了一通,還是不理解的話,答案早就寫(xiě)在以下幾篇里:
《是 持續(xù)增量更新 的 背景緣由甜點(diǎn)》 的 “飯后甜點(diǎn)不能當(dāng)主食吃” 一節(jié) (推薦);
《基本功:是隨時(shí)隨地可受用的 深度思考秘訣》 的 “所以如何正確地思考” 一節(jié);
《這是一份 簡(jiǎn)潔有力的 認(rèn)知地圖》 的 “認(rèn)知地圖” 一節(jié);
還有近期在掘金開(kāi)源的《獨(dú)家解析 | Android 深度思考寫(xiě)作技巧》 的 “公式” 一節(jié) ——
這幾處都有 就正確的思維方式 提供方法論依據(jù) 以及手把手示范。
一旦熟悉了這套方法論,那些沒(méi)完沒(méi)了的爭(zhēng)論,你會(huì)不會(huì)參與?我想大概率不會(huì),因?yàn)槟阋谎劬涂闯?這些言論中不包含基于事實(shí)的思考,不過(guò)是 憑主觀感覺(jué)、個(gè)人喜好 的自說(shuō)自話。
參與到這種扯淡中 是對(duì)自己的不尊重,所以你不會(huì)參與。
綜上
MVP 的本質(zhì)是對(duì) MVC 的依賴倒置,借此來(lái)解決 邏輯復(fù)用難 以及 實(shí)現(xiàn)替換難 的問(wèn)題,
因?yàn)樵?MVP 下,UI 邏輯和業(yè)務(wù)邏輯全在 Presenter 中寫(xiě),UI 和 Model 的實(shí)現(xiàn),可以隨意替換,
也即如上文介紹的,通過(guò)同一套 Presenter 中的邏輯,可以驅(qū)動(dòng)不同品牌不同型號(hào)的耳機(jī)的線控。(注意 UI 的全稱是 “用戶接口”,臺(tái)灣的術(shù)語(yǔ)更準(zhǔn)確,叫 “用戶介面”。UI 不是狹義上的頁(yè)面,UI 就是 UI)
MVVM 的本質(zhì)是對(duì) View 數(shù)據(jù)的映射,借此來(lái)在軟工背景下解決 視圖調(diào)用的一致性問(wèn)題。
MVP 和 MVVM 二者的區(qū)別在于,前者是廣義的架構(gòu)模式,普遍適用、抓大放小;后者是狹義上的架構(gòu)模式,專用于頁(yè)面開(kāi)發(fā),可以解決例如 視圖調(diào)用的一致性問(wèn)題,來(lái)規(guī)避不可預(yù)期的錯(cuò)誤。
也即 MVP 和 MVVM 本質(zhì)上毫無(wú)關(guān)系,沒(méi)有誰(shuí)演化自誰(shuí)。
Jetpack MVVM 是 MVVM 模式在 Android 下的一個(gè)落地,也即除了解決 視圖調(diào)用的一致性問(wèn)題,還因地制宜地解決了其他一致性問(wèn)題,從而規(guī)避各種不可預(yù)期的錯(cuò)誤,讓軟件開(kāi)發(fā)的工作得以完成得又快又好。
這樣說(shuō),你理解了嗎?
版權(quán)聲明
本文以 CC 署名-非商業(yè)性使用-禁止演繹 4.0 國(guó)際協(xié)議 發(fā)行。
Copyright ? 2019-present KunMinX
文中提到的 關(guān)于 “MVP 和 MVVV 各自的本質(zhì)及區(qū)別” 的具體描述、”用戶介面與耳機(jī)線控“ 的舉例、”DataBinding 與函數(shù)式編程數(shù)據(jù)驅(qū)動(dòng)框架的關(guān)系“ 的具體描述、”Jetpack MVVM 和 MVVM 關(guān)系“ 的描述、”Lifecycle、LiveData、ViewModel、DataBinding 等架構(gòu)組件的存在意義“ 等多處 對(duì)特定現(xiàn)象及其本質(zhì)的概括,均屬于本人獨(dú)立原創(chuàng)的成果,本人對(duì)此享有最終解釋權(quán)。
任何個(gè)人或組織在轉(zhuǎn)載全文,或引用本文中上述提到的 描述、舉例或本質(zhì)概括 時(shí),須注明原作者和出處。未經(jīng)授權(quán)不得用于洗稿、廣告包裝等商業(yè)用途。
總結(jié)
以上是生活随笔為你收集整理的mvp的全称_是让人提神醒脑的 MVP、MVVM 关系精讲!的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 荣耀x2中继模式只有百兆
- 下一篇: 分段函数if语句_C语言函数系列之库函数