常見的架構概念

在本節中，您將找到在更廣泛的應用程式開發領域中指導架構決策的經過驗證的原則，以及它們如何專門應用於 Flutter 的資訊。這是對推薦架構和最佳實踐相關詞彙和概念的初步介紹，以便在本指南的後續部分中可以更詳細地進行探討。

關注點分離是應用程式開發中的一項核心原則，它透過將應用程式的功能劃分為不同的、自包含的單元來促進模組化和可維護性。從宏觀角度來看，這意味著將 UI 邏輯與業務邏輯分開。這通常被稱為分層架構。在每一層內，您都應該透過功能或特性進一步分離您的應用程式。例如，您的應用程式的認證邏輯應該與搜尋邏輯位於不同的類中。

在 Flutter 中，這也適用於 UI 層中的小部件。您應該編寫可重用、精簡的小部件，它們應包含儘可能少的邏輯。

Flutter 應用程式應分層編寫。分層架構是一種軟體設計模式，它將應用程式組織成不同的層，每一層都有特定的角色和職責。通常，根據複雜性，應用程式被分為 2 到 3 層。

• UI 層 - 顯示業務邏輯層公開的資料給使用者，並處理使用者互動。這通常也稱為“表示層”。
• 邏輯層 - 實現核心業務邏輯，並促進資料層和 UI 層之間的互動。通常稱為“領域層”。邏輯層是可選的，只有當您的應用程式具有在客戶端上發生的複雜業務邏輯時才需要實現。許多應用程式只關注向用戶顯示資料並允許使用者更改該資料（俗稱 CRUD 應用程式）。這些應用程式可能不需要此可選層。
• 資料層 - 管理與資料來源（如資料庫或平臺外掛）的互動。將資料和方法暴露給業務邏輯層。

這些被稱為“層”，因為每一層只能與它上面或下面的層進行通訊。UI 層不應該知道資料層的存在，反之亦然。

您應用中的每種資料型別都應該有一個單一資料來源（SSOT）。資料來源負責表示本地或遠端狀態。如果資料可以在應用程式中修改，SSOT 類應該是唯一可以這樣做的類。

這可以大大減少應用程式中的錯誤數量，並簡化程式碼，因為您將始終只有同一資料的副本。

通常，應用程式中任何給定型別資料的源都包含在一個名為Repository的類中，該類是資料層的一部分。對於您應用程式中的每種資料型別，通常有一個儲存庫類。

此原則還可以應用於應用程式的各層和元件，以及單個類中。例如，Dart 類可以使用getter從 SSOT 欄位派生值（而不是具有多個需要獨立更新的欄位），或者使用一組記錄來組合相關值（而不是可能索引不同步的並行列表）。

單向資料流（UDF）是指一種設計模式，它有助於將狀態與顯示該狀態的 UI 解耦。簡單來說，狀態從資料層流經邏輯層，最終流向 UI 層中的小部件。使用者互動產生的事件流向相反的方向，從表示層流回邏輯層，再到資料層。

在 UDF 中，從使用者互動到重新渲染 UI 的更新迴圈如下所示：

1. [UI 層] 由於使用者互動而發生事件，例如點選按鈕。小部件的事件處理程式回撥呼叫邏輯層中的某個類公開的方法。
2. [邏輯層] 邏輯類呼叫儲存庫公開的方法，這些方法知道如何修改資料。
3. [資料層] 儲存庫更新資料（如果需要），然後將新資料提供給邏輯類。
4. [邏輯層] 邏輯類儲存其新狀態，並將其傳送到 UI。
5. [UI 層] UI 顯示檢視模型的新狀態。

新資料也可以從資料層開始。例如，儲存庫可能會輪詢 HTTP 伺服器以獲取新資料。在這種情況下，資料流只完成一半的旅程。最重要的一點是，資料更改始終發生在SSOT（即資料層）中。這使您的程式碼更易於理解，不易出錯，並防止建立格式錯誤或意外的資料。

Flutter 是宣告式的，這意味著它構建 UI 來反映應用程式的當前狀態。當狀態發生變化時，您的應用程式應觸發依賴於該狀態的 UI 的重建。在 Flutter 中，您經常會聽到這被描述為“UI 是狀態的函式”。

至關重要的是，您的資料應驅動 UI，而不是反之。資料應該是不可變的和持久的，而檢視應包含儘可能少的邏輯。這最大限度地減少了應用程式關閉時資料丟失的可能性，並使您的應用程式更易於測試，並且更能抵抗錯誤。

架構的每個部分都應該有一組定義明確的輸入和輸出。例如，邏輯層中的檢視模型應該只接受資料來源作為輸入，例如儲存庫，並且只公開格式化後的命令和資料供檢視使用。

以這種方式使用清晰的介面可以使您在不更改使用介面的任何程式碼的情況下，替換類的具體實現。

使軟體可擴充套件的原則也使軟體更容易測試。例如，您可以透過模擬儲存庫來測試檢視模型中自包含的邏輯。檢視模型測試不需要您模擬應用程式的其他部分，您可以將 UI 邏輯與 Flutter 小部件本身分開進行測試。

您的應用程式也將更靈活。新增新邏輯和新 UI 將是直接且風險低的。例如，新增新的檢視模型不會破壞資料層或業務邏輯層的任何邏輯。

下一節將解釋應用程式架構中任何給定元件的輸入和輸出的概念。

由於本網站的部分內容正在不斷更新，我們歡迎您的反饋！