本文就是 視圖與邏輯分離之道序篇
中的彩蛋, "?? 猜一猜復(fù)雜的業(yè)務(wù)邏輯應(yīng)該怎么處理", 快來了解一下吧??
了解 GetArch
? 為什么做GetArch
GetArch源于一顆熱愛編程的 ??
Flutter 狀態(tài)管理五花八門, 各種"快速開發(fā)模板"也悄然流行起來，但是Dart軟件架構(gòu)卻很少有人研究.
我認(rèn)為這可能與目前國內(nèi)軟件普遍采用前后端分離設(shè)計(jì)，讓App內(nèi)部沒有太多業(yè)務(wù)邏輯, 亦或是Flutter開發(fā)者大多來自前端, 主要關(guān)注UI展示而對軟件架構(gòu)不重視導(dǎo)致的.
隨著Serverless的崛起,借助Flutter的跨平臺優(yōu)勢, 產(chǎn)品的業(yè)務(wù)邏輯重心將會逐步遠(yuǎn)離服務(wù)器,轉(zhuǎn)移到個人設(shè)備上. 那么為軟件設(shè)計(jì)一個高內(nèi)聚,低耦合,方便多人協(xié)同開發(fā)的架構(gòu)至關(guān)重要.
這并不是說, 個人開發(fā)的獨(dú)立軟件就沒有考慮架構(gòu)的必要.
軟件架構(gòu)的意義就在于讓持續(xù)開發(fā)的成本最小化, 這也是業(yè)界 面向過程編程迅速被面向?qū)ο缶幊烫蕴母驹?
站在巨人的肩膀上, 結(jié)合實(shí)際開發(fā)需求, GetArch從構(gòu)思成為現(xiàn)實(shí).
?? GetArch特性 & 解決的問題
- ?? 拒絕重復(fù)勞動: 扔掉需要刪刪改改的"開發(fā)模板"吧
- ?? 完全解耦: 不止是視圖與邏輯之間
- ?? 模塊化設(shè)計(jì): 靈活替換任何代碼模塊, 讓App化身忒修斯之船, 追求極致的代碼復(fù)用率
- ?? 輕松上手: 預(yù)置QuickStart等模塊, 成為搭建應(yīng)用的腳手架, 幫助你專注于業(yè)務(wù)邏輯 (如果Flutter不提供 material.dart 和 cupertino.dart, 那開發(fā)時長可能得加倍??)
- ?? 無副作用: 在已有的項(xiàng)目中依然可以引入GetArchCore, 不會排斥已有代碼, 加入GetArch生態(tài), 何必重新開始? ??
- ?? 豈止于Flutter? GetArchCore不依賴于Flutter SDK, 你可以基于GetArch搭建一個后端服務(wù), 或者讓App中的業(yè)務(wù)邏輯搬到后臺.
?? 引入GetArch的利弊
很多來自前端的開發(fā)者可能不太適應(yīng)非UI代碼部分作為程序的主體, 認(rèn)為這樣做是在"畫蛇添足".
我認(rèn)為, 是否引入架構(gòu), 應(yīng)當(dāng)從開發(fā)成本的角度考慮.
如果你的程序編寫完畢之后就無需添加新的功能, 并且應(yīng)用功能獨(dú)特, 未來都沒有復(fù)用的需求, 那么設(shè)計(jì)一個架構(gòu), 再區(qū)分各個模塊確實(shí)沒有必要, 能用就行. 強(qiáng)行引入架構(gòu), 徒增前期開發(fā)成本, 得不償失.
但是如果程序還需要持續(xù)維護(hù), 那么使用一個設(shè)計(jì)合理的架構(gòu), 以降低迭代開發(fā)成本, 還是十分必要的.
?? GetArch的愿景
GetArchCore完全開源, 任何遵循GetArch架構(gòu)設(shè)計(jì), 實(shí)現(xiàn)GetArchCore中相應(yīng)接口的App都可以成為其他App的一個模塊, 我希望能夠有更多的人加入GetArch生態(tài), 并讓更多的人從GetArch中獲益, 讓GetArch終結(jié)重復(fù)造無意義輪子的歷史.
</br></br>
GetArch —— Dart 軟件架構(gòu)設(shè)計(jì)的終極解決方案
</br></br>
?? 傳送區(qū)
GetArch 宇宙 ??
將get_arch_core添加到y(tǒng)aml中, 實(shí)現(xiàn)對應(yīng)的接口, 所有基于GetArch的程序都能成為你的輪子!
GetArch宇宙歡迎你的加入??
GetArch 核心模塊, 所有使用GetArch架構(gòu)的程序都依賴于GetArchCore.
快速開始基礎(chǔ)設(shè)施包, 里面包含了 Http請求, Socket, 本地存儲, Dialog的基礎(chǔ)實(shí)現(xiàn), 幫助使用者專注于App的業(yè)務(wù)邏輯功能
GetState是一個基于MVVM的狀態(tài)管理package.
GetState目前并不依賴于GetArchCore, 但是作為GetState的作者, 我希望更多的人 嘗試使用GetState ??
當(dāng)然, 后續(xù)版本的GetState肯定會加入GetArch生態(tài), 以獲得一致的使用體驗(yàn).
GetArch架構(gòu)設(shè)計(jì)參考鏈接
- The Clean Architecture
- Applying The Clean Architecture
- Clean Architecture Essentials
- Implementing Clean Architecture - What is a use case?
- Applying Clean Architecture on Android
- Explicit architecture
</br>
?? GetArch設(shè)計(jì)理念
軟件開發(fā)唯一的真理是“軟件必然修改”
軟件架構(gòu)存在的意義就在于" 如何讓軟件適應(yīng)需求變化的成本做到最低".
?? 實(shí)體類
首先, 思考一個問題:
"作為一個面向?qū)ο蟮膽?yīng)用軟件, 其最本質(zhì)的, 最核心的東西是什么?"
答案當(dāng)然是"對象", 對象所擁有的屬性與動作, 構(gòu)成了軟件的行為, 通過各個對象之間的交互, 完成軟件設(shè)計(jì)時所要求的功能.
對象不依賴任何其他事物, 是構(gòu)成一個面向?qū)ο蟪绦虻淖罨镜囊?
?? 用例 ?? ?? ??
有了對象, 程序還需要對外界不同的請求做出不同的回應(yīng), 顯然, 用例(UseCase)只依賴于對象, 描述了對象的動作和各對象之間的交互, 沒有對象, 用例就沒有存在的意義.
用例不依賴除對象之外的任何其他事物.
?? 接口 ??
無論是鍵盤輸入, 語音輸入, 還是從數(shù)據(jù)庫讀取, 從網(wǎng)絡(luò)訪問, 程序總是需要一個接口以輸入數(shù)據(jù).
同樣的,無論是通過命令行打印, 還是通過圖形界面繪制輸出, 程序總是需要一個方式向外界傳遞數(shù)據(jù)處理的結(jié)果.
作為接口, 它一定不是具象化的, 就好比USB接口, 總是可以接入各種符合USB標(biāo)準(zhǔn)的設(shè)備, 而不是只為某一種設(shè)備服務(wù).
接口不依賴于對象和用例之外的其他事物.
?? 基礎(chǔ)設(shè)施 ?? ?? ??
從抽象到具體, 從特定到普適. 對于程序而言, 最不重要的就是"數(shù)據(jù)從哪輸入", "數(shù)據(jù)輸出到哪"了.
例如一個"讀書App", 要實(shí)現(xiàn)"展示電子書"的功能, 那么電子書是從數(shù)據(jù)庫讀取, 還是從SD卡讀取, 亦或是從網(wǎng)絡(luò)下載, 這些都只是數(shù)據(jù)輸入方式, 如果說僅僅是因?yàn)橐岩粋€原本只能從SD卡讀取電子書的軟件, 改造成能夠從網(wǎng)絡(luò)下載電子書的軟件, 需要花費(fèi)巨大的力氣重構(gòu)的話, 那這真是個極其失敗的軟件.
基礎(chǔ)設(shè)施應(yīng)該是一個軟件中替換成本最低的部分
小結(jié)
GetArch 架構(gòu)層次展示
GetArch目錄結(jié)構(gòu)
以上目錄結(jié)構(gòu)自上而下的順序?qū)?yīng)相關(guān)層次的上下次序, 在IDE中目錄結(jié)構(gòu)并不一致, 不要看錯了.??
??這張圖可能就是本文最有價值的部分了, 注意觀察
</br></br></br>
寫在最后
本文是一篇介紹性的文章, GetArch使用教程將在后續(xù)的文章中講解, 敬請期待??
