Open Kuan-Hsien opened 5 years ago
因應未來功能增加或是需求變更，把程式碼控制在較好維護和擴充的範圍。
M - V - X 的架構中，把程式分成三個層級，分別有各自的職責。
說明：左邊是 User，中間是 M-V-X 模式設計的應用程式，右邊是儲存資料的伺服器或是資料庫。
C 指的是 Controller，負責接收來自 View 的事件，和操作 Model 處理資料。 關於 MVC 的架構有幾種不同的說法，其中一種如下圖：
說明：使用者操作畫面時，View 接收事件交給 Controller，Controller 操作 Model 處理資料，Model 處理完資料後再更新畫面。
在 Android 開發時，XML 可以當作 View，Activity 和 Fragment 則擔任 Controller。
主要的好處是依職責區分單元。但這個架構有幾點可以討論：
由於需要在 Activity 控制 View 的元件，導致 Activity 同時需要負責 View 和 Controller 的角色。 但 Activity 最重要的職責是管理介面的操作和顯示。當需求增加，Activity 會龐大而難以維護。
如果設計成 Model 持有 View ，以在處理資料完成時通知 View 更新 UI，會增加耦合性。 可以使用觀察者模式，由 View 觀察資料，讓資料在變化時主動通知 View 做相對應的更新。
P 是 Presenter，負責擔任 View 與 Model 之間的橋樑。一個 Presenter 一般只對應到一個 View。 和 MVC 不同的地方是，View 和 Model 不直接互動，完全透過 Presenter 來進行溝通，成為兩個獨立的單元。 說明：使用者操作畫面時，View 接收事件交給 Presenter，Presenter 操作 Model 處理資料，Model 處理完資料後通知 Presenter，再由 Presenter 通知 View 更新畫面。
使用 MVP 架構來開發 Android App 時，會把 Activity 與 Fragment 當作 View，專心負責控制使用者介面。程式的邏輯則放在 Presenter 中。
相較於 MVC 架構，MVP 架構更重視元件之間的分離，分幾個點做討論。
由於邏輯放到 Presenter 中，Activity 和 Fragment 可以專心處理自己的生命週期，和負責管理介面的操作和顯示。
達到較高的可維護性，方便重用，利於單元測試。
實作上會在各元件間加入 interface，用 interface 來規範方法。彼此間互相注入 interface 來進行操作來降低耦合性。相對的，由於依賴 interface 提供的方法來操作，需求修改時，interface 和實作需要一起修改。
為了達到一個 Presenter 只處理一個 View 的邏輯，可能會有一些重複的 Presenter 和 interface。
MVVM 中的 VM 指的是 ViewModel，一樣負責接收從 View 傳來的使用者操作事件，並使用 Model 提供的方法來處理資料。主要差異是由數據來驅動 View 的更新，當資料改變時，UI 自動更新。
說明：把資料存在 ViewModel 中，View 觀察 ViewModel 中的資料。當使用者操作畫面時，View 接收事件交給 ViewModel，ViewModel 操作 Model 處理資料，Model 處理完資料後通知 ViewModel 更新資料。由於 View 觀察 ViewModel 中的資料，資料更新後 View 會收到更新，並更新畫面。
實作上只需要透過觀察者模式來完成當事件發生時，自動通知觀察者。即可達到 MVVM 中數據驅動 UI 變化的效果。
而由於 Google 在 2017 出的 Architecture Component 中有幾個元件可以方便的實現 MVVM 架構，建議可以參考 sunflower 或 codelab 來進一步學習。
我這次分成三個階段來介紹實作：
https://github.com/Kuan-Hsien/android-mvvm-demo
MVVM 架構有幾個主要的優點：
事件都透過資料的變化來觸發，資料成為最關鍵的因素。
在 MVC / MVP 中，都需要有 View 的引用來更新 UI。但在 MVVM 中，由View 主動觀察資料，在資料變化後收到通知，而自動更新。 ViewModel 不需要知道 View 是誰。
ViewModel 中可以減少大量通知 View 的程式碼，專心的管理流程。 Activity 和 Fragment 不用儲存資料狀態，可以專心管理介面的操作和顯示，並妥善控制生命週期。
第一場讀書會的內容大致如上，後續就是現場 Demo 時針對 Observer-Pattern, ViewModel, LiveData, Databinding, Room 和 Repository-Pattern 的講解和討論。有任何問題再請大家幫忙補充。
References:
MVVM — 架構篇：書讀得多，人自然就好看起來 https://medium.com/ken-do-everything/mvvm-%E6%9E%B6%E6%A7%8B%E7%AF%87-%E6%9B%B8%E8%AE%80%E5%BE%97%E5%A4%9A-%E4%BA%BA%E8%87%AA%E7%84%B6%E5%B0%B1%E5%A5%BD%E7%9C%8B%E8%B5%B7%E4%BE%86-4fd595581e7f
目標：
因應未來功能增加或是需求變更，把程式碼控制在較好維護和擴充的範圍。
M - V - X 的架構
M - V - X 的架構中，把程式分成三個層級，分別有各自的職責。
優點：
MVC (Model — View — Controller)
C 指的是 Controller，負責接收來自 View 的事件，和操作 Model 處理資料。 關於 MVC 的架構有幾種不同的說法，其中一種如下圖：
Android 中的 MVC
在 Android 開發時，XML 可以當作 View，Activity 和 Fragment 則擔任 Controller。
討論
主要的好處是依職責區分單元。但這個架構有幾點可以討論：
1. Activity 和 Fragment 的角色（以 Activity 為例）：
由於需要在 Activity 控制 View 的元件，導致 Activity 同時需要負責 View 和 Controller 的角色。 但 Activity 最重要的職責是管理介面的操作和顯示。當需求增加，Activity 會龐大而難以維護。
2. View 和 Model 的關係：
如果設計成 Model 持有 View ，以在處理資料完成時通知 View 更新 UI，會增加耦合性。 可以使用觀察者模式，由 View 觀察資料，讓資料在變化時主動通知 View 做相對應的更新。
MVP (Model — View — Presenter)
P 是 Presenter，負責擔任 View 與 Model 之間的橋樑。一個 Presenter 一般只對應到一個 View。 和 MVC 不同的地方是，View 和 Model 不直接互動，完全透過 Presenter 來進行溝通，成為兩個獨立的單元。
說明：使用者操作畫面時，View 接收事件交給 Presenter，Presenter 操作 Model 處理資料，Model 處理完資料後通知 Presenter，再由 Presenter 通知 View 更新畫面。
Android 中的 MVP
使用 MVP 架構來開發 Android App 時，會把 Activity 與 Fragment 當作 View，專心負責控制使用者介面。程式的邏輯則放在 Presenter 中。
討論
相較於 MVC 架構，MVP 架構更重視元件之間的分離，分幾個點做討論。
1. 職責的區分：
由於邏輯放到 Presenter 中，Activity 和 Fragment 可以專心處理自己的生命週期，和負責管理介面的操作和顯示。
2. View 和 Model 完全獨立：
達到較高的可維護性，方便重用，利於單元測試。
3. 使用 interface 互相操作：
實作上會在各元件間加入 interface，用 interface 來規範方法。彼此間互相注入 interface 來進行操作來降低耦合性。相對的，由於依賴 interface 提供的方法來操作，需求修改時，interface 和實作需要一起修改。
4. 一個 Presenter 只處理一個 View 的邏輯：
為了達到一個 Presenter 只處理一個 View 的邏輯，可能會有一些重複的 Presenter 和 interface。
MVVM (Model — View — ViewModel)
MVVM 中的 VM 指的是 ViewModel，一樣負責接收從 View 傳來的使用者操作事件，並使用 Model 提供的方法來處理資料。主要差異是由數據來驅動 View 的更新，當資料改變時，UI 自動更新。
Android 中的 MVVM
實作上只需要透過觀察者模式來完成當事件發生時，自動通知觀察者。即可達到 MVVM 中數據驅動 UI 變化的效果。
而由於 Google 在 2017 出的 Architecture Component 中有幾個元件可以方便的實現 MVVM 架構，建議可以參考 sunflower 或 codelab 來進一步學習。
我這次分成三個階段來介紹實作：
MVVM demo (in Java):
https://github.com/Kuan-Hsien/android-mvvm-demo
討論
MVVM 架構有幾個主要的優點：
1. 資料驅動：
事件都透過資料的變化來觸發，資料成為最關鍵的因素。
2. 下層元件不需要知道上層元件：
在 MVC / MVP 中，都需要有 View 的引用來更新 UI。但在 MVVM 中，由View 主動觀察資料，在資料變化後收到通知，而自動更新。 ViewModel 不需要知道 View 是誰。
3. 職責分離：
ViewModel 中可以減少大量通知 View 的程式碼，專心的管理流程。 Activity 和 Fragment 不用儲存資料狀態，可以專心管理介面的操作和顯示，並妥善控制生命週期。
第一場讀書會的內容大致如上，後續就是現場 Demo 時針對 Observer-Pattern, ViewModel, LiveData, Databinding, Room 和 Repository-Pattern 的講解和討論。有任何問題再請大家幫忙補充。
References:
MVVM — 架構篇：書讀得多，人自然就好看起來 https://medium.com/ken-do-everything/mvvm-%E6%9E%B6%E6%A7%8B%E7%AF%87-%E6%9B%B8%E8%AE%80%E5%BE%97%E5%A4%9A-%E4%BA%BA%E8%87%AA%E7%84%B6%E5%B0%B1%E5%A5%BD%E7%9C%8B%E8%B5%B7%E4%BE%86-4fd595581e7f