架構推薦和資源

關注點分離是最重要的架構原則。資料層將應用程式資料暴露給應用程式的其餘部分，幷包含應用程式的大部分業務邏輯。UI 層顯示應用程式資料並監聽使用者的事件。UI 層包含用於 UI 邏輯和小部件的單獨類。

倉庫模式是一種軟體設計模式，它將資料訪問邏輯與應用程式的其餘部分隔離。它在應用程式的業務邏輯和底層資料儲存機制（資料庫、API、檔案系統等）之間建立了一個抽象層。在實踐中，這意味著建立倉庫類和服務類。

關注點分離是最重要的架構原則。這種特定的分離使您的程式碼更不易出錯，因為您的小部件保持“啞”狀態。

ChangeNotifier API 是 Flutter SDK 的一部分，是一種方便的方法，可以讓您的 Widget 觀察 ViewModel 中的更改。

有很多選項來處理狀態管理，最終的決定取決於個人偏好。請閱讀關於 我們的 ChangeNotifier 推薦 或 其他流行的選項。

邏輯應封裝在 ViewModel 上的方法中。檢視應包含的唯一邏輯是

• 簡單的 if 語句，根據 ViewModel 中的標誌或可為空欄位來顯示和隱藏小部件
• 依賴於小部件來計算的動畫邏輯
• 基於裝置資訊（如螢幕尺寸或方向）的佈局邏輯。
• 簡單的路由邏輯

只有當您的應用程式具有超出 ViewModel 範圍的複雜邏輯，或者您發現自己在 ViewModel 中重複邏輯時，才需要領域層。在非常大的應用程式中，用例很有用，但在大多數應用程式中，它們會增加不必要的開銷。

在具有複雜邏輯要求的應用程式中使用。

資料更新應僅從資料層流向 UI 層。UI 層中的交互發送到資料層進行處理。

Commands 可以防止應用程式中的渲染錯誤，並標準化 UI 層將事件傳送到資料層的方式。請閱讀架構案例研究中的 Commands。

不可變資料對於確保必要的更改僅發生在適當的位置（通常是資料或領域層）至關重要。由於不可變物件在建立後無法修改，因此必須建立一個新例項來反映更改。此過程可防止 UI 層中的意外更新，並支援清晰的單向資料流。

您可以使用軟體包來幫助在資料模型中生成有用的功能，freezed 或 built_value。這些可以生成常見的模型方法，如 JSON ser/des、深度相等性檢查和複製方法。如果您的模型很多，這些程式碼生成包可能會為您的應用程式增加大量的構建時間。

使用單獨的模型會增加冗長性，但可以防止 ViewModel 和用例中的複雜性。

在大規模應用中使用。

依賴注入可以防止您的應用程式擁有全域性可訪問的物件，這使得您的程式碼更不易出錯。我們建議您使用 provider 包來處理依賴注入。

Go_router 是編寫 90% Flutter 應用程式的首選方法。有一些特定的用例 go_router 無法解決，在這種情況下，您可以使用 Flutter Navigator API 直接使用或嘗試在 pub.dev 上找到其他軟體包。

我們建議根據它們所代表的架構元件來命名類。例如，您可能有以下類

• HomeViewModel
• HomeScreen
• UserRepository
• ClientApiService

為了清晰起見，我們不建議使用可能與 Flutter SDK 中的物件混淆的名稱。例如，您應該將共享小部件放在名為 ui/core/ 的目錄中，而不是名為 /widgets 的目錄中。

倉庫類是應用程式中所有資料的真相來源，並促進與外部 API 的通訊。建立抽象倉庫類允許您建立不同的實現，這些實現可用於不同的應用程式環境，例如“開發”和“暫存”。

• 為每個服務、倉庫和 ViewModel 類編寫單元測試。這些測試應單獨測試每個方法的邏輯。
• 為檢視編寫小部件測試。測試路由和依賴注入尤為重要。

模擬物件不像它們那樣關注任何給定方法的內部工作原理，而是關注輸入和輸出。如果您在編寫應用程式程式碼時牢記這一點，您將被迫編寫模組化、輕量級的函式和類，這些函式和類具有明確定義的輸入和輸出。