標籤：鏈式 規則 com repos 影響 轉換 9.png one 簡單的
原文連結：https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ 過去的幾個月中，在Tuenti上與同行例如@pedro_g_s和@flipper83進行了一些討論。我決定去寫一篇關於Android APP架構的文章。 寫這個文章的目的是為了向你們展示一些我自己的方法，這些方法已經存在我的腦中好幾個月了，主要來自於我自己的學習和研究。
開始行動我們都知道編寫高品質的軟體是很難的而且很複雜：這不僅僅是滿足需求，而應該是健壯的，易維護的，可測試的和可擴充的。所以提出的“簡單的架構”理念是一種好的開發任何軟體應用的方法。 想法很簡單：“簡潔架構”代表一組實踐方式它的系統包含以下內容：
- 獨立的架構
- 可測試的
- 獨立的UI
- 獨立的資料庫
- 獨立的外部機構
並不是必須而且只能用4個圈表示(上所示），但是這裡有一條從屬規則必須知道。這個從屬規則是：代碼的依賴只能是指向內部的，而且只有內圈能知道外圈的內容。也就是外部的圈是無法知道內部圈的內容的。 以下是一些能讓我們更好的熟悉和理解這個方法的一些名詞解釋：
- Entities：應用的業務對象
- Use Cases: 也叫互動器。使用者執行個體由與Entities的資料流組成。
- Interface Adapter：這裡設定一些適配器將資料轉換成user case 和entities能用的格式。Presenters 和 Controllers 屬於這一層。
- Framework 和Drivers: 這裡是真正的實現地區，如：UI，工具，frameworks等等。
為了更好的解釋，請參考這篇文章和視頻。
我們的方案：我會通過一個簡單的例子來解釋這個方案；建立一個簡單的APP，這個APP實現的功能是：通過後台雲來擷取朋友或者使用者的列表，當使用者點擊列表中的一項就會顯示一個詳細的頁面。
Android架構目的是為了獨立業務單元，業務單元對於外圍是未知的，然而這個業務單元能夠進行獨立測試。 我提議將工程分成3層來實現，每層都有自己的目的並與其它層獨立。 因為每層都有自己的資料模型所以才能實現獨立（你可以看到在代碼中有一個資料對應表被用來進行完成資料的傳送,這個是不想通過整個應用使用公用一套模型的代價） 以下是原理圖：注釋：我沒有使用外部的類庫（除了使用gson去解析json資料和junit，mockito,robolectic和espresso 用來測試）。這樣做的目的就是為了例子更簡潔。另外不要討厭去添加ORMs去儲存硬碟資料或者其他相關的注入架構或者其他的工具或者你熟悉的庫。（記住不要重複的製造車輪）
Presentation 層 呈現者在這層中由inteactors組成，他們在主UI線程之外的線程上工作，然後通過回呼函數來傳回資料並更新UI。 如果你想要一個更好的關於MVP和MVVM在Android UI的影響，可以看這篇文章。
Domain 層商務規則在這裡，所有的邏輯關係也在這裡。查看Android 工程，你會發現所有的Interactors的實現在這裡。這一層由無Android無關的純Java代碼構成。所有外部組件使用介面來對業務塊進行聯絡。
Data層應用中所有的資料都來自這一層，他們通過UserRepository（這個介面在domain層）的實現，使用Repository Pattern的一種策略，通過原廠模式，擷取各種不同的資料來源取決於中央條件。 在執行個體中，當我們通過Id來擷取使用者執行個體的時候，首先會選擇磁碟緩衝，如果不存在的話會通過網路擷取資料然後儲存在本地磁碟中。 這種機制的前提條件是資料來源對於用戶端來說是透明的，它不必關係資料是來自記憶體，磁碟或者是雲資料庫。只要相信可以獲得到資料即可。注釋：在執行個體中，因為只是為了學習，我通過一個檔案系統和android preferences來實現簡單和原始的磁碟緩衝。再次銘記不要重複造車輪。
Error Handling這個是我們應該總是優先討論，如果分享你的解決方案會更好。 我的策略是使用回呼函數，如果一些錯誤發生在資料庫，那麼回調會有兩個方法onResponse()和onError().第二個方法是會將異常封裝在一個叫"ErorBundle"的類中：這個方法會帶來一些困難因為存在一個鏈式的回調，一個接一個的知道錯誤到了presentation層，但是如果代碼寫的易讀會將這種困難度減低。另一方面，我會實現一個evetn bus 系統來處理錯誤事件，這個系統叫GOTO . 在我看來，有時如果訂閱太多的事件，但是又沒有控制緊密會導致一些事件丟失。
Testing對於測試工作，我選了幾種對應不同層的解決方案。
- Prestation layer:使用android instrumtntation 和espresso去做整合和功能測試。
- Domain layer：Junit 加mockito 對於單元測試。
- Data Layer:Robolectric加junit加mockito用於整合和單元測試。
代碼展示代碼在github上https://github.com/pedrovgs/EffectiveAndroidUI/,對於代碼檔案夾結構需要說明的是不同的層使用不同的模組。
- presentation:這是android 模組，代表presetntaion Layer.
- domain：純粹的Java模組無任何Android關聯。
- data:擷取資料的Android 模組。
- data-test:針對Data layer的測試。由於使用Robolectric的限制，所以我要單獨分離出來。
總結：正如Uncle bob 所說“Architecture is about Intent,not Frameworks".我們在工作中總是會遇到各種挑戰，但是如果使用這些技術，對於應用可以做到以下：
作為總結我強烈建議你去試試然後分享你的結果和經驗。我們相信持續的改進一直是一種好的事情。 我希望你能通過本文獲得有用的資訊。
如何簡單的構建Android？
