架構建議與資源

關注點分離是架構最重要的原則。資料層嚮應用的其餘部分公開應用資料，幷包含應用中大部分的業務邏輯。UI 層顯示應用資料並監聽使用者的事件。UI 層包含用於 UI 邏輯和 Widget 的單獨類。

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

關注點分離是架構最重要的原則。這種特定的分離方式使程式碼出錯率大大降低，因為你的 Widget 保持為“啞（dumb）”元件。

ChangeNotifier API 是 Flutter SDK 的一部分，是一種讓 Widget 觀察 ViewModel 變化的便捷方式。

有很多選項可以處理狀態管理，最終的決定取決於個人喜好。閱讀我們的 ChangeNotifier 建議 或 其他熱門選項。

邏輯應封裝在 ViewModel 的方法中。View 中唯一可以包含的邏輯是：

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

只有當你的應用具有極其複雜的邏輯，導致 ViewModel 變得臃腫，或者你發現自己在 ViewModel 中重複編寫邏輯時，才需要使用領域層。在超大型應用中，用例（Use-cases）很有用，但在大多數應用中，它們會增加不必要的開銷。

用於具有複雜邏輯需求的應用。

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

Command 可以防止應用中的渲染錯誤，並標準化 UI 層向資料層傳送事件的方式。閱讀 架構案例研究 中關於 Command 的內容。

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

你可以使用軟體包來幫助生成資料模型中的有用功能，例如 freezed 或 built_value。它們可以生成常見的模型方法，如 JSON 序列化/反序列化、深度相等性檢查和複製方法。如果你有大量的模型，這些程式碼生成包可能會顯著增加應用的構建時間。

使用單獨的模型會增加冗餘，但能防止 ViewModel 和用例中出現複雜性。

用於大型應用。

依賴注入可以防止應用擁有全域性可訪問的物件，從而降低程式碼的出錯率。我們建議使用 provider 軟體包來處理依賴注入。

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

我們建議按照架構元件所代表的含義來命名類。例如，你可能會有以下類：

• HomeViewModel
• HomeScreen
• UserRepository
• ClientApiService

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

Repository 類是應用中所有資料的真實來源，並促進與外部 API 的通訊。建立抽象 Repository 類允許你建立不同的實現，這些實現可用於不同的應用環境，例如“開發”和“預釋出”。

• 為每個 Service、Repository 和 ViewModel 類編寫單元測試。這些測試應單獨測試每個方法的邏輯。
• 為 View 編寫 Widget 測試。測試路由和依賴注入尤為重要。

模擬物件（Fake）並不關心給定方法的內部工作原理，它們更關心輸入和輸出。如果在編寫應用程式碼時考慮到這一點，你將被迫編寫具有明確輸入和輸出的模組化、輕量級的函式和類。