今天會非常簡單介紹的MVP架構， 帶大家大致理解MVP架構

個人覺得先簡單了解一下架構後，在後續學元件並結合架構實作會更好理解跟上手，所以就決定寫MVP和MVVM兩個架構的概念文章(Android Studio初始是傳統MVC架構就不談了)，後面再來討論元件運用，那就開始吧(=´ᴥ`)

核心概念

• 定義：將使用者介面（UI）、商業邏輯和資料處理三者分離
• 目標：解決傳統MVC模式中 View 和 Controller 過於緊密的問題，提升程式碼的可讀性、可維護性與可測試性

MVP意思

View

Activity 或 Fragment

• 職責：
  • 顯示畫面 (佈局、元件)
  • 接收使用者的輸入與操作 (點擊、滑動、輸入文字)
  • 將使用者操作通知給 Presenter
• 原則：不包含任何商業邏輯，只等待 Presenter 的指令來更新畫面

Presenter

View與Model之間的橋樑

• 職責：
  • 接收 View 傳來的事件通知
  • 向 Model 請求或提交資料
  • 根據 Model 回傳的資料執行邏輯判斷
  • 將處理結果回傳，命令 View 更新
• 原則：不直接操作 Android API 或 UI 元件 (例如 findViewById 或 setText...)，透過呼叫 View 提供的介面方法來間接控制 View，主要為了讓 Presenter 更易測試與解耦

Model

資料的提供者與管理者

• 職責：
  • 提供資料from Database, Network API, Local Cache
  • 執行資料的Create, Read, Update, Delete
• 原則：只專注於資料本身，不知道 Presenter 的存在，也不知道資料會如何顯示

互動流程

1. 在 View 上進行操作
2. View捕捉到事件，立即通知 Presenter
3. Presenter 接收到請求，向 Model 請求驗證資料
4. Model 執行資料操作，並將結果回傳給 Presenter
5. Presenter 根據 Model 回傳的結果，進行邏輯判斷
6. Presenter 呼叫 View 的介面方法，命令 View 更新 UI

Contract

• 用途：使用interface來定義View 和Presenter 之間所有可能的溝通方法
• 結構：通常是一個巢狀介面

public interface MainContract {
    interface view {
    }
    interface presenter {
    }
    //Contract 中通常會只定義view 與presenter 介面，Model 介面視實作需求可有可無
    interface model {
    }
}

MVP就先介紹到這，明天會來介紹MVVM架構，明天見(･-･)b