視圖與邏輯分離之道1- GetArch, 禿頭拯救者 (Dart軟件架構設計)

時間 2020-06-27

標籤視圖邏輯分離之道 getarch 禿頭拯救 dart 軟件架構設計欄目系統架構简体版

原文原文鏈接

本文就是序篇中的彩蛋, "💡 猜一猜複雜的業務邏輯應該怎麼處理", 快來了解一下吧😉html

瞭解 GetArch

❓ 爲何作GetArch

GetArch源於一顆熱愛編程的 💕前端

Flutter 狀態管理五花八門, 各類"快速開發模板"也悄然流行起來，可是Dart軟件架構卻不多有人研究.
我認爲這可能與目前國內軟件廣泛採用先後端分離設計，讓App內部沒有太多業務邏輯, 亦或是Flutter開發者大多來自前端, 主要關注UI展現而對軟件架構不重視致使的.
隨着Serverless的崛起,藉助Flutter的跨平臺優點, 產品的業務邏輯重心將會逐步遠離服務器,轉移到我的設備上. 那麼爲軟件設計一個高內聚,低耦合,方便多人協同開發的架構相當重要.android

這並非說, 我的開發的獨立軟件就沒有考慮架構的必要.
軟件架構的意義就在於讓持續開發的成本最小化, 這也是業界面向過程編程迅速被面向對象編程淘汰的根本緣由.git

站在巨人的肩膀上, 結合實際開發需求, GetArch從構思成爲現實.github

🔧 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宇宙歡迎你的加入😎網絡

🌏 GetArchCore GitHub | Pub

GetArch 核心模塊, 全部使用GetArch架構的程序都依賴於GetArchCore.

🚀 GetArchQuickStart GitHub | Pub

快速開始基礎設施包, 裏面包含了 Http請求, Socket, 本地存儲, Dialog的基礎實現, 幫助使用者專一於App的業務邏輯功能

📝 GetState GitHub | Pub

GetState是一個基於MVVM的狀態管理package.
GetState目前並不依賴於GetArchCore, 可是做爲GetState的做者, 我但願更多的人嘗試使用GetState 😉

固然, 後續版本的GetState確定會加入GetArch生態, 以得到一致的使用體驗.

GetArch架構設計參考連接

💡 GetArch設計理念

軟件開發惟一的真理是「軟件必然修改」
軟件架構存在的意義就在於" 如何讓軟件適應需求變化的成本作到最低".

👴 實體類

首先, 思考一個問題:
"做爲一個面向對象的應用軟件, 其最本質的, 最核心的東西是什麼?"

答案固然是"對象", 對象所擁有的屬性與動做, 構成了軟件的行爲, 經過各個對象之間的交互, 完成軟件設計時所要求的功能.

對象不依賴任何其餘事物, 是構成一個面向對象程序的最基本的要素.

🤙 用例 🏃 🕺 🏌

有了對象, 程序還須要對外界不一樣的請求作出不一樣的迴應, 顯然, 用例(UseCase)只依賴於對象, 描述了對象的動做和各對象之間的交互, 沒有對象, 用例就沒有存在的意義.

用例不依賴除對象以外的任何其餘事物.

🙏 接口 📭

不管是鍵盤輸入, 語音輸入, 仍是從數據庫讀取, 從網絡訪問, 程序老是須要一個接口以輸入數據.
一樣的,不管是經過命令行打印, 仍是經過圖形界面繪製輸出, 程序老是須要一個方式向外界傳遞數據處理的結果.
做爲接口, 它必定不是具象化的, 就比如USB接口, 老是能夠接入各類符合USB標準的設備, 而不是隻爲某一種設備服務.

接口不依賴於對象和用例以外的其餘事物.

🦶 基礎設施 🛴 🚲 🛵

從抽象到具體, 從特定到普適. 對於程序而言, 最不重要的就是"數據從哪輸入", "數據輸出到哪"了.

例如一個"讀書App", 要實現"展現電子書"的功能, 那麼電子書是從數據庫讀取, 仍是從SD卡讀取, 抑或是從網絡下載, 這都不是軟件的根基, 若是說僅僅是由於要把一個本來只能從SD卡讀取電子書的軟件, 改形成可以從網絡下載電子書的軟件, 須要花費巨大的力氣重構的話, 那麼這個軟件的設計真的是糟糕透了.