本文就是 序篇 中的彩蛋, "? 猜一猜複雜的業務邏輯應該怎麼處理", 快來了解一下吧?
瞭解 GetArch
❓ 為什麼做GetArch
GetArch源於一顆熱愛程式設計的 ?
Flutter 狀態管理五花八門, 各種"快速開發模板"也悄然流行起來，但是Dart軟體架構卻很少有人研究.
我認為這可能與目前國內軟體普遍採用前後端分離設計，讓App內部沒有太多業務邏輯, 亦或是Flutter開發者大多來自前端, 主要關注UI展示而對軟體架構不重視導致的.
隨著Serverless的崛起,藉助Flutter的跨平臺優勢, 產品的業務邏輯重心將會逐步遠離伺服器,轉移到個人裝置上. 那麼為軟體設計一個高內聚,低耦合,方便多人協同開發的架構至關重要.
這並不是說, 個人開發的獨立軟體就沒有考慮架構的必要.
軟體架構的意義就在於讓持續開發的成本最小化, 這也是業界 程式導向程式設計迅速被物件導向程式設計淘汰的根本原因.
站在巨人的肩膀上, 結合實際開發需求, GetArch從構思成為現實.
? GetArch特性 & 解決的問題
- ? 拒絕重複勞動: 扔掉需要刪刪改改的"開發模板"吧
- ? 完全解耦: 不止是檢視與邏輯之間
- ? 模組化設計: 靈活替換任何程式碼模組, 讓App化身忒修斯之船, 追求極致的程式碼複用率
- ? 輕鬆上手: 預置QuickStart等模組, 成為搭建應用的腳手架, 幫助你專注於業務邏輯 (如果Flutter不提供 material.dart 和 cupertino.dart, 那開發時長可能得加倍?)
- ? 無副作用: 在已有的專案中依然可以引入GetArchCore, 不會排斥已有程式碼, 加入GetArch生態, 何必重新開始? ?
- ? 豈止於Flutter? GetArchCore不依賴於Flutter SDK, 你可以基於GetArch搭建一個後端服務, 或者讓App中的業務邏輯搬到後臺.
? 引入GetArch的利弊
很多來自前端的開發者可能不太適應非UI程式碼部分作為程式的主體, 認為這樣做是在"畫蛇添足".
我認為, 是否引入架構, 應當從開發成本的角度考慮.
如果你的程式編寫完畢之後就無需新增新的功能, 並且應用功能獨特, 未來都沒有複用的需求, 那麼設計一個架構, 再區分各個模組確實沒有必要, 能用就行. 強行引入架構, 徒增前期開發成本, 得不償失.
但是如果程式還需要持續維護, 那麼使用一個設計合理的架構, 以降低迭代開發成本, 還是十分必要的.
? GetArch的願景
GetArchCore完全開源, 任何遵循GetArch架構設計, 實現GetArchCore中相應介面的App都可以成為其他App的一個模組, 我希望能夠有更多的人加入GetArch生態, 並讓更多的人從GetArch中獲益, 讓GetArch終結重複造無意義輪子的歷史.
GetArch —— Dart 軟體架構設計的終極解決方案
? 傳送區
GetArch 宇宙 ?
將get_arch_core新增到yaml中, 實現對應的介面, 所有基於GetArch的程式都能成為你的輪子!
GetArch宇宙歡迎你的加入?
GetArch 核心模組, 所有使用GetArch架構的程式都依賴於GetArchCore.
快速開始基礎設施包, 裡面包含了 Http請求, Socket, 本地儲存, Dialog的基礎實現, 幫助使用者專注於App的業務邏輯功能
GetState是一個基於MVVM的狀態管理package.
GetState目前並不依賴於GetArchCore, 但是作為GetState的作者, 我希望更多的人 嘗試使用GetState ?
當然, 後續版本的GetState肯定會加入GetArch生態, 以獲得一致的使用體驗.
GetArch架構設計參考連結
- 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
? GetArch設計理念
軟體開發唯一的真理是“軟體必然修改”
軟體架構存在的意義就在於" 如何讓軟體適應需求變化的成本做到最低".
? 實體類
首先, 思考一個問題:
"作為一個物件導向的應用軟體, 其最本質的, 最核心的東西是什麼?"
答案當然是"物件", 物件所擁有的屬性與動作, 構成了軟體的行為, 通過各個物件之間的互動, 完成軟體設計時所要求的功能.
物件不依賴任何其他事物, 是構成一個物件導向程式的最基本的要素.
? 用例 ? ? ?
有了物件, 程式還需要對外界不同的請求做出不同的回應, 顯然, 用例(UseCase)只依賴於物件, 描述了物件的動作和各物件之間的互動, 沒有物件, 用例就沒有存在的意義.
用例不依賴除物件之外的任何其他事物.
? 介面 ?
無論是鍵盤輸入, 語音輸入, 還是從資料庫讀取, 從網路訪問, 程式總是需要一個介面以輸入資料.
同樣的,無論是通過命令列列印, 還是通過圖形介面繪製輸出, 程式總是需要一個方式向外界傳遞資料處理的結果.
作為介面, 它一定不是具象化的, 就好比USB介面, 總是可以接入各種符合USB標準的裝置, 而不是隻為某一種裝置服務.
介面不依賴於物件和用例之外的其他事物.
? 基礎設施 ? ? ?
從抽象到具體, 從特定到普適. 對於程式而言, 最不重要的就是"資料從哪輸入", "資料輸出到哪"了.
例如一個"讀書App", 要實現"展示電子書"的功能, 那麼電子書是從資料庫讀取, 還是從SD卡讀取, 亦或是從網路下載, 這些都只是資料輸入方式, 如果說僅僅是因為要把一個原本只能從SD卡讀取電子書的軟體, 改造成能夠從網路下載電子書的軟體, 需要花費巨大的力氣重構的話, 那這真是個極其失敗的軟體.
基礎設施應該是一個軟體中替換成本最低的部分
小結
GetArch 架構層次展示
GetArch目錄結構
以上目錄結構自上而下的順序對應相關層次的上下次序, 在IDE中目錄結構並不一致, 不要看錯了.?
?這張圖可能就是本文最有價值的部分了, 注意觀察
寫在最後
本文是一篇介紹性的文章, GetArch使用教程將在後續的文章中講解, 敬請期待?