轉(zhuǎn)載請標(biāo)明出處 http://www.reibang.com/p/e8e81a8f08b1
工程作者Jorge J. Barroso (Karumi)
簡述
工程原理基于Clean Architecture.
工程例子基于MVP sample
之前的圖浪秘，看下對比欧瘪，Presentation layer 與? Data Layer 之間新增 domain layer? . App 分成三層.
MVP:? 是MVP sample里的
Domain:包含業(yè)務(wù)邏輯. Domain layer 的驅(qū)動是Presenter通過use cases 或interactor . User case 可以支持所有Developer從Presentation Layer 想執(zhí)行的事情
Use case 通常翻譯成"用例"? 何為Use case?? "是一件事的場景描述"
Repository: 是MVP sample里的
?重點(diǎn)概念
與MVP sample最大的區(qū)別是使用Domain layer 和 use cases . 把Domain Layer層從Presenter 移出是幫助避免Presenter存在重復(fù)的domain 代碼(e.g.Task filters).
Use cases 定義了一組App需要的操作.它的Class名稱帶有明顯目的宝与，會提高可讀性(seetasks/domain/usecase/).
Use cases對于我們重復(fù)使用domain代碼是十分有益的.CompleteTask是一個很好的例子梗醇，例如它同時使用了TaskDetailPresenter與TasksPresenter.?
通過命令模式command pattern Use cases 在后臺線程完成執(zhí)行.Domain Layer 的存在完全減弱 Android SDK 和 第三方 lib 的依賴.(Java獨(dú)立代碼)
問題/紀(jì)要
Use cases 運(yùn)行在主線程之外，這對Android apps來說是一個好的解決方案. 這樣做盡可能避免堵塞UI線程. 我們決定使用命令模式command pattern來執(zhí)行線程池中的Use cases. 但我們也可以通過RxJava 和 Promises 來實(shí)現(xiàn).
我們使用異步的倉庫(Data Source)但沒有必要一定這樣做. 因?yàn)?Use cases 就已經(jīng)不在主線程執(zhí)行的. 這樣會盡可能的保持原生的例子.
我們建議為View闯捎、Domain椰弊、API層使用不同的Model . 但在這個Case下所有Model都是不變的，因此沒必要重復(fù)創(chuàng)建維護(hù)他們.? 如果View包含Android相關(guān)聯(lián)字段瓤鼻，我們就使用兩種Model . 一個用在Domian Layer 一個用在View Layer ,并且維護(hù)一個mapper去轉(zhuǎn)換彼此.
CallBack(回調(diào)) 相關(guān)存在一個 onError() 方法, 在真正的app中應(yīng)該包含報錯的信息.
測試性
應(yīng)用Clean Architecture思想后
Domain Layer ：過單元測試(Unit Test) 可測
也可以通過集成測試來擴(kuò)展秉版，把它覆蓋到從View 到 Repository
三層分離，上層依賴下層茬祷，所以下層永遠(yuǎn)不知道有上層清焕。這三層皆可獨(dú)立測試
依賴
除了依賴一些測試lib , 其他一律不需要
特征
復(fù)雜性 - 可理解性
使用框架/lib/tool? ??? 沒有
概念復(fù)雜性
中等偏下 .? 這還是MVP ，不過是以增加新的 Domain Layer 來處理業(yè)務(wù)邏輯.
代碼量
新增Domain Layer層后，添加了一些class 和代碼量如圖
可維護(hù)性
易于拓展和新增功能 / 學(xué)習(xí)陳本
非常簡單. 這種方式更加擅長
