清潔和新Android架構的認知訴求

一個根本性的變化即將改變Android的核心工作方式。但你為什么要關心？而且，為什么這是一件好事？讓我們來看看。
Android的新架構組件現已正式并固化。毫無疑問，View Models和LiveData等架構組件將使Android開發世界中新手的生活變得更加輕松。

但是對于經驗豐富的開發人員來說，問題將不可避免地出現在新的架構組件如何以及在何處與干凈架構的概念一致，正如Bob叔叔所倡導的那樣。

你可能會問我們為什么要擔心干凈的建筑？答案很簡單 - 清潔架構基于人類與軟件開發周期的關系，這意味著它歸結為一個簡單而單一的“關注點分離”原則。清潔架構不僅限于特定的平臺解決方案，Android Lifecycle的概念及其周圍的解決方案也是如此。

考慮到這個問題，我想看看谷歌最近的一個樣本，使用他們的架構組件，如何符合清潔架構的基本概念。清晰體系結構的核心概念在圖片中進行了總結，對于任何了解這里提出的清潔體系結構的人來說都非常熟悉：

清潔架構中的核心原則

“內圈中的任何東西都不能知道外圈中的某些東西。特別是，外圈中聲明的東西的名稱不能被內圈中的代碼所提及。這包括函數，類，變量，或任何其他指定的軟件實體。“

我拍的樣本是Google 代碼實驗室的“帶有視圖的房間”樣本。

盡管有許多使用方法的清潔架構實現，如MVP，MVVM等，它們為Android空間提供了可行的解決方案，但我的問題是，如果我們能夠維護清潔架構的核心概念，那就是：“內部圓圈中的代碼不得提及外部圓圈中聲明的內容的名稱“不帶任何框架，只需使用Android體系結構組件即可。

“帶有視圖的房間”是一個簡單的應用程序，它列出了數據庫中的單詞，并允許您添加新單詞。

應用程序中有八個類：

1.MainActivity

2. NewWordActivity
   3.Word
3. WordDao
   5. WordListAdapter
4. WordRepository
5. WordRoomDatabase
   8. WordViewModel
      沒有太大困難，我可以實現理想的組織，成功率約為90％：
      

一些擔憂

在 LiveData 作為一個元素不會在組織的任何地方出現。雖然確實 LiveData 是一個設施/機制，但它不是政策意義上的實體。

干凈的架構說，“外圈是機制。內圈是政策。” 在此基礎上，它將DB放在最外層。但是，如果不打破核心原則，我無法將DB放在外圈。

我知道這更多地表明當前技術中的數據庫如何變得更加廣泛，而不是實現細節。

我唯一關注的另一個問題是，當ViewModel 坐在UI控制器中時，關注細節的分離感 ，而 ListAdapter 應該處理顯示的數據。適配器能夠觀察任何變化的視圖模型。如果我們這樣做，那么我們可以說適配器幾乎決定了從存儲庫端顯示的數據。UI負責維護組件的正確UI外觀。考慮到這一點，我在適配器中移動了視圖模型，它向UI公開了一個額外的方法“insert（..）”。修改后的代碼在這里：ViewModel的房間。

通過這樣做，我可以更清楚地了解干凈的架構圈子，它 LiveData 是存儲庫使用的內部工具

結論

Android清潔架構是一個可以在沒有大量框架的情況下實現的目標，只要我們專注于關注的認知分離，以及測試設施，它在Kotlin中變得更加語言驅動，而不會打擾關于工具和設施的性質。我們始終堅持這樣的原則：“總的來說，你走的越遠，軟件就越高。” 更高級別僅僅意味著更具包容性，就像現在的數據庫實現一樣。我們不再關心它是什么類型的DB，只要它保持暴露的接口完好無損。由于開源的能量，我們可以通過認知鏡頭看到今天的工具，而不是將我們的手和思想聯系起來。反過來，這也使得開源移動得更快。