架構建議和資源
本頁面介紹了架構最佳實踐、它們為何重要以及我們是否推薦將它們用於您的 Flutter 應用程式。您應將這些建議視為建議，而非硬性規定，並應根據您應用程式的獨特需求進行調整。
本頁面上的最佳實踐有優先順序之分，反映了 Flutter 團隊對其推薦的強度。
- 強烈推薦：如果您開始構建新應用程式，應始終實施此建議。您應認真考慮重構現有應用程式以實施此實踐，除非這樣做與您當前的方法根本衝突。
- 推薦：此實踐很可能會改進您的應用程式。
- 有條件推薦：此實踐在某些情況下可以改進您的應用程式。
關注點分離
您應該將應用程式劃分為 UI 層和資料層。在這些層內，您應該根據職責將邏輯進一步劃分為類。
| 建議 | 描述 |
|---|---|
使用定義清晰的資料層和 UI 層。 強烈推薦 | 關注點分離是最重要的架構原則。資料層嚮應用程式的其餘部分公開應用程式資料，幷包含應用程式中的大部分業務邏輯。UI 層顯示應用程式資料並監聽使用者的使用者事件。UI 層包含獨立的 UI 邏輯和 Widget 類。 |
在資料層中使用儲存庫模式。 強烈推薦 | 儲存庫模式是一種軟體設計模式，它將資料訪問邏輯與應用程式的其餘部分隔離開。它在應用程式的業務邏輯和底層資料儲存機制（資料庫、API、檔案系統等）之間建立了一個抽象層。實際上，這意味著建立儲存庫類和服務類。 |
在 UI 層中使用 ViewModel 和 View。（MVVM） 強烈推薦 | 關注點分離是最重要的架構原則。這種特殊的劃分使您的程式碼出錯的可能性大大降低，因為您的 Widget 仍然是“啞巴”的。 |
使用 有條件推薦 | ChangeNotifier API 是 Flutter SDK 的一部分，是一種方便的方式來讓您的 Widget 觀察 ViewModel 中的更改。
|
不要在 Widget 中放置邏輯。 強烈推薦 | 邏輯應封裝在 ViewModel 的方法中。檢視應包含的唯一邏輯是
|
使用領域層。 有條件推薦 | 只有當您的應用程式具有超出 ViewModel 複雜度的邏輯，或者您發現自己在 ViewModel 中重複邏輯時，才需要領域層。在非常大的應用程式中，用例很有用，但在大多數應用程式中，它們會增加不必要的開銷。
|
資料處理
小心處理資料可使您的程式碼更易於理解，出錯的可能性更小，並防止建立格式錯誤或意外的資料。
| 建議 | 描述 |
|---|---|
使用單向資料流。 強烈推薦 | 資料更新應僅從資料層流向 UI 層。UI 層中的互動被髮送到資料層進行處理。 |
使用 推薦 | Commands 可防止您的應用程式出現渲染錯誤，並標準化 UI 層將事件傳送到資料層的方式。請閱讀 架構案例研究 中的 Commands 部分。 |
使用不可變資料模型。 強烈推薦 | 不可變資料對於確保任何必要的更改僅在適當的位置（通常是資料層或領域層）發生至關重要。由於不可變物件在建立後無法修改，因此您必須建立新例項來反映更改。此過程可防止 UI 層中的意外更新，並支援清晰的單向資料流。 |
使用 freezed 或 built_value 生成不可變資料模型。 推薦 | 您可以使用軟體包來幫助生成資料模型中有用的功能，例如 freezed 或 built_value。這些可以生成常見的模型方法，如 JSON 序列化/反序列化、深度相等性檢查和 copy 方法。如果您有很多模型，這些程式碼生成包會顯著增加應用程式的構建時間。 |
建立單獨的 API 模型和領域模型。 有條件推薦 | 使用單獨的模型會增加冗餘，但可以防止 ViewModel 和用例中的複雜性。
|
應用程式結構
組織良好的程式碼對應用程式本身以及參與程式碼的團隊都有益。
| 建議 | 描述 |
|---|---|
使用依賴注入。 強烈推薦 | 依賴注入可防止您的應用程式擁有全域性可訪問的物件，從而降低程式碼出錯的可能性。我們建議您使用 provider 軟體包來處理依賴注入。 |
使用 go_router 進行導航。 推薦 | Go_router 是編寫 90% Flutter 應用程式的首選方式。有些特定用例 go_router 無法解決，在這種情況下，您可以使用 Flutter Navigator API 直接使用，或嘗試在 pub.dev 上找到的其他軟體包。 |
為類、檔案和目錄使用標準化的命名約定。 推薦 | 我們建議為類命名，以反映它們所代表的架構元件。例如，您可能有以下類
為了清晰起見，我們不建議使用可能與 Flutter SDK 物件混淆的名稱。例如，您應該將共享 Widget 放在名為 |
使用抽象儲存庫類 強烈推薦 | 儲存庫類是應用程式中所有資料的真實來源，並促進與外部 API 的通訊。建立抽象儲存庫類允許您建立不同的實現，這些實現可用於不同的應用程式環境，例如“開發”和“暫存”。 |
測試
良好的測試實踐使您的應用程式具有靈活性。它還使新增新邏輯和新 UI 變得簡單且風險較低。
| 建議 | 描述 |
|---|---|
單獨且一起測試架構元件。 強烈推薦 | * 為每個服務、儲存庫和 ViewModel 類編寫單元測試。這些測試應單獨測試每個方法的邏輯。
|
建立測試的模擬（並編寫利用模擬的程式碼）。 強烈推薦 | 模擬（Fakes）不像關注任何給定方法的內部工作方式，更關注輸入和輸出。如果您在編寫應用程式程式碼時考慮這一點，您將被迫編寫具有清晰定義的輸入和輸出的模組化、輕量級的函式和類。 |
推薦資源
#- 程式碼和模板
- Compass app 原始碼 - 一個功能齊全、健壯的 Flutter 應用程式的原始碼，實現了許多這些建議。
- very_good_cli - 由 Flutter 專家 Very Good Ventures 建立的 Flutter 應用程式模板。此模板會生成類似的應用程式結構。
- 文件
- Very Good Engineering 架構文件 - Very Good Engineering 是 VGV 的文件網站，包含技術文章、演示和開源專案。它包括關於 Flutter 應用程式架構的文件。
- 使用 ChangeNotifier 進行狀態管理演練 - 一個使用 Flutter SDK 中的原語進行狀態管理的入門介紹。
- 工具
- Flutter 開發者工具 - DevTools 是 Dart 和 Flutter 的效能和除錯工具套件。
- flutter_lints - 一個包含 Flutter 團隊推薦的 Flutter 應用 lint 的軟體包。使用此軟體包可在團隊中推廣良好的編碼實踐。
反饋
#由於本網站的該部分正在不斷發展，我們歡迎您的反饋！