MVP那些事兒(1) 用場景說話

時間 2019-11-17

標籤 mvp 那些事兒場景說話简体版

原文原文鏈接

引言

隨着這幾年移動互聯網的快速發展，移動互聯網技術也獲得了推進，輔助架構設計型的框架和思想層出不窮，從井噴的2015年到如今，開發者們愈來愈離不開這些高性能、高效率的工具，而製造這些工具的公司或我的，也被推到神壇，受猿們的膜拜。與此同時，Google在今年的io大會上發佈了本身的官方框架Architecture Components【譯】，能夠說是至關的應景了。時不我待，瞭解架構的知識，而且靈活的應用是咱們程序員將來必不可少的技能，這系列文章是介紹MVP架構的，但願能對閱讀此文的朋友們帶來些收穫。性能

一、如何實現一個MVP框架的基本原則，以及MVP的使用場景，是我想寫這篇文章的初衷，同時也是對我本身學習的知識作一個整體的融合。學習

二、爲了不一上來生硬的開場，我先以一個簡單的開發例子做爲引子，以初學者的角度去看待問題，同時也能兼顧到初學者，到後面咱們會一步步提示。因此你也能夠選擇直接跳轉到。。。。優化

三、由於講架構，可能是場景描述，因此代碼量比較少，習慣於經過代碼理解的同窗，我儘可能多些並反覆描述。

場景

假設實現一個商品的列表展現功能，咱們首先須要一個用戶界面，包含一些控件來供用戶操做，好比列表展現。咱們大多數狀況下使用一個Fragment做爲控件的載體，在Fragment中直接調用網絡請求的工具並等待回調方法被執行後去刷新UI去展現數據，因此對於這個需求的代碼量並非不少。如今需求增長了，要加入下拉刷新和上拉加載更多，通常是監聽這兩個事件，在相應的回調中處理數據，沒幾行代碼，依舊寫在Fragment中，而需求又一次增長了，要加入排序，緊接着咱們處理排序邏輯，代碼依舊寫在Fragment中，接着又增長需求了，加入詳情頁的跳轉，可能跳轉前要處理些業務邏輯，接着又要增長需求了，列表視圖能夠從宮格式轉變爲瀑布式，須要改變控件的樣式，……接着新需求又來了，可編輯的列表項，能夠刪除和修改列表項，同時數據要同步到服務器，需求又來了，編輯列表項須要動畫功能……直到這個時候咱們回頭再看看咱們的Fragment，這個時候咱們可能沒法容忍Fragment裏混亂複雜的邏輯了。

從功能性需求的角度來講，功能完整、軟件正常運行，這是沒有問題的，但回過頭來我看了一下代碼覺的並非那麼「沒問題」，在不使用架構的狀況下，咱們無感知的將邏輯代碼業務以及視圖代碼都堆積到了Activity當中，這樣的角色能夠說是至關的臃腫的，同時很是不利於將來的擴展，因而非功能性的需求須要知足：Activity優化與擴展性。