CleanArchitectureForAndroid
1.0.0
該項目是我的書《 Android乾淨體系結構》中介紹的清潔體系結構的鬆散實現。這是用Kotlin編寫的本地Android項目。它演示了書中介紹的關鍵原則以及它們如何應用於現實生活項目。
我將努力使該項目保持最新，並使用它來展示體系結構的優勢：在選擇第三方解決方案時，可伸縮性，可檢驗性和靈活性。
簡單
“這裡介紹的複雜性是過度的！ ”
我同意。如果這是一個最終項目，而不會添加任何新功能，那麼乾淨的體系結構將過於復雜。但是，現實是移動項目很少是最終的。用戶反饋，營銷需求，新技術 - 這些因素和其他因素都導致幾乎每個項目的持續更改。因此，現在似乎過多的複雜性可能會獎勵我們的變化時間到來。這將是當乾淨的建築閃耀時。
附帶說明：在某些方面，我通過引入不同的技術來故意過度複雜這個項目。目的是展示即使在現實生活中，一個項目可能會隨著時間的推移而增長以包括多個技術解決方案，該建築仍然有效。
映射器作為類與映射擴展功能
在模型之間映射時，我們有幾個選項。主要決策是映射器類和映射擴展功能之間的決定。
雖然擴展功能更簡潔，但使用它們來映射限制我們的測試框架的選擇（例如，Mockito無法存根靜態函數）。
如何注入映射器擴展功能？我們可以做到。但是，這幾乎完全消除了簡潔的好處。它還使實施變得更加困難。
因此，我選擇了更多的詳細混凝土映射器類。
跳過Google的架構組件
Google的體系結構組件最大的問題是它們將Android詳細信息洩漏到演示層中。這樣可以防止演示層真正成為UI不可知論。
架構組件的另一個問題是，它們對ViewModel付出了太多的責任。它們使其持續存在它不擁有的狀態，從而導致潛在的數據同步錯誤。
由於這些原因，在仍在遵循MVVM的同時，該項目依賴於Kotlin流動而不是Livedata ，並實現了純ViewModels而不是Google。
模擬框架
該項目中都使用了Mockito-Kotlin和Mockk，以演示每個外觀的使用方式。
我的個人偏愛仍然是嘲諷 - 凱特林。我發現使用時更容易讀取和遵循代碼。在寫作時，從每個存儲庫的恆星數量來看，該行業似乎傾向於Mockk。
有人問我使用假貨。我已經探索了假貨，發現它們過於冗長，太昂貴了。
依賴注入框架
依賴注入（DI）是大多數現代應用程序的關鍵部分，可幫助我們獲取構建應用程序的對象。它還有助於管理他們的範圍。在Android世界中，最受歡迎的選擇是刀柄（建在匕首之上）和Koin。
選擇刀具的主要原因是：
XML與JetPack組成
為什麼不呢？我仍然對JetPack組成有很多擔憂。即便如此，對於我來說，無論選擇哪種UI機制，對我來說都很重要。作為練習，我邀請您嘗試將UI層從組合替換為XML，反之亦然，而無需更新演示層。
亞馬遜上的Android的清潔體系結構
清潔編碼器博客上的清潔架構
歡迎對該項目的貢獻。請隨時報告任何問題或分叉，以進行更改並提出拉動請求。
該項目根據MIT許可證的條款分發。有關詳細信息，請參見License.MD。
