Android Firebase Kotlin java Mvp Mvc Mvvm chat
1.0.0
MVC是Android中的一種干淨的方法，將視圖從控制器中脫穎而出。控制器僅負責更新模型，一旦模型更新了它可以通知視圖，然後可以使用適當的回調更新視圖。傳統的MVC是有一個
模型：充當數據模型
查看：對用戶的視圖處理可以是UI
控制器：控制模型和視圖之間的相互作用，其中視圖調用控制器以更新模型。視圖可以在需要時調用多個控制器。
可以使用MVP方法克服MVC的一些缺點。 MVP中的主持人包含所有業務邏輯，此類遠離Android上下文或與Android相關的依賴關係，這些依賴性可通過簡單地在測試模塊中使用演示者類，從而為文本業務邏輯提供靈活性。與Android相關的依賴性在測試中創造了複雜性。主持人沒有任何Android依賴性，例如上下文，視圖等，所有模型更新和網絡請求都是通過主持人完成的。模型更新或網絡請求完成後，使用回調通過主持人來更新視圖，以查看主持人。沒有模型和網絡請求可以直接訪問視圖。
MVVM涉及一種數據綁定方法，以使代碼簡短並減少Java類中的視圖處理代碼。視圖模型負責更新視圖，並且一旦將視圖模型綁定到視圖，則視圖獲取有關其更新事件的通知。如果模型通過用戶單擊更新，則將模型發送回調以查看模型，該模型會在視圖綁定時自動更新視圖。 MVVM降低了代碼大小，但MVVM的實施非常困難，很難根據MVVM調試大型項目。
？
為該項目選擇正確的體系結構涉及對需要開發的模塊的理解。某些功能在MVC上效果很好，有些功能具有MVP，有些功能具有MVVM。很難在MVVM上進行調試，特別是由於數據綁定和實時數據而沒有單方面數據流的項目。如果應用程序從源接收連續的數據流，則需要常規的UI-UPATE，並且主要具有（80-90％）的單面通信（例如：將日誌發送到Android應用程序的電子設備（例如太陽能電池應用程序），例如太陽能電池應用程序，Interverters應用程序，或任何其他設備的狀態可與MVVM一起良好，因為實時數據可以很好地工作。調試這些MVVM應用程序可能很容易，因為大量數據流是單方面的。
當我們擔心通過Java測試框架（非Android）測試業務邏輯WRT單元測試時，MVP是編寫Android項目的好方法。由於Java測試框架只能解析Java依賴項，並且乾淨的演示者層沒有與Android相關的依賴項，例如上下文，共享Preferences或任何其他com.android。 * 包裹。 MVP的缺點是，它最終以使用MVC或MVVM編寫的相同功能編寫20-25％的額外代碼。如果您真的對模塊的測試用例和單位測試感興趣，則MVP很好。對於使用Java測試套件的MVP，只需製作主持人實例並運行測試功能即可。
例如：新主持人（）。 testSomeFunction（） 。
MVC是在Android中廣泛使用的技術。 Google本身在MVC中寫了它的存儲庫多年了。現在，Google正在為其GitHub存儲庫採用MVVM，因為這些存儲庫很小，主要是樣本。由於缺乏com.android的依賴關係，因此可以通過不使用Java特定測試工具的Android測試框架來測試MVC應用程序。 * Java特定工具中的軟件包。
例子：
注意：沒有一個最好的體系結構。如果有一個，就不需要學習其他架構。正確的體系結構的選擇取決於幾個因素，例如初始需求，數據流，可伸縮性，維護，更新（CRS），測試要求。
除了這三個Android體系結構外，還有另外一個稱為“ MVI - 模型視圖意圖”的體系結構。這在Android開發人員中不是很受歡迎。如果您對MVI感興趣，請檢查此鏈接。
https://github.com/saksham24/android-simple-mvi-pattern-with-mvp-mvvm-collaboration
