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