可維護性是我們在實際開發系統時，需要認真考慮的的一個重要方面。它決定了系統修改、修復和更新的難易程度。只有當所有組件都得到良好維護并且軟件項目沒有什么不同時，系統才會以最佳方式運行。

如果您的項目具有可維護高的良好架構，開發人員可以輕松了解項目并進行準確的更改以獲得性能，同時縮短開發、測試和發布周期。

項目的架構是決定項目組件維護難易程度的關鍵因素。分層架構是為 React 等前端框架編寫可維護組件的最佳架構之一。

因此，本文將討論如何使用分層架構在 React 中編寫易于維護的組件以及您應該避免的錯誤。

什么是分層架構，為什么要使用它？

分層架構是一種軟件設計模式，它將應用程序組織成多個層或層，每個層都有一組特定的職責。這些層按層次組織，較高層依賴較低層的功能。大多數分層架構具有三個或四個標準層。

在分層架構中，每一層都可以獨立開發和測試，改變一層不會影響其他層。這種分離允許開發人員創建更易于維護和更新的有組織、模塊化和可擴展的系統。 

此外，這種方法允許對應用程序進行更改而無需重寫大部分代碼，從而降低引入錯誤或破壞現有功能的風險。

讓我們以 3 層架構為例，看看它如何改善開發體驗。

三層架構

顧名思義，三層架構由三個主要層組成：

• 表現層
• 業務邏輯層
• 數據訪問層

表示層管理用戶交互并將數據呈現給用戶。該層可以采用 Web 界面、桌面應用程序或移動應用程序的形式。它與業務邏輯層通信以執行操作和檢索數據。

業務邏輯層負責實施應用程序的業務規則和工作流。該層應該完全獨立于表示層并且不了解用戶界面。它應該包含所有應用程序邏輯和算法，并與數據訪問層通信以檢索所需的數據。

數據訪問層負責與應用程序的數據源進行交互。該層負責數據的檢索和存儲，應與業務邏輯層分開。它應該包括與數據庫訪問、API 調用和其他外部數據源相關的所有代碼。

如何在 React 中使用三層架構

現在讓我們看看如何將分層架構原則應用到我們的 React 應用程序中。

數據訪問層

該層通常實現為一組實用函數，可以被各種自定義 Hooks 重用。考慮以下用于檢索 API 數據的 fetchData() 實用程序函數。

export default async function fetchData() {
  const response = fetch('https://jsonplaceholder.typicode.com/users/1').then(
    (res) => {
      if (res.ok) return res.json();
      return Promise.reject(res);
    }
  );
  return response;
}

每當您需要檢索 API 數據而無需編寫重復代碼時，都可以在業務邏輯層中使用此功能。您可以用道具替換獲取 URL，并隨著項目的增長根據需要修改功能。在測試 API 調用時，您可以使用模擬數據調用此函數以簡化過程。

業務邏輯層

該層通常實現為一組可以跨組件重用的自定義 Hook。考慮以下 useUserData() 自定義 Hook，它用于檢索用戶數據。

import React from "react";
import fetchData from "../util/fetchData";


const useUserData = () => {
  const [userData, setUserData] = useState([]);
  useEffect(() => {
    fetchData()
      .then((data) => setUserData(data))
      .catch((res) => console.error(res.status));
  }, []);
  return [userData];
};


export default useUserData;

如您所見，此處調用了數據訪問層的 fetchData() 函數。為了使這個鉤子更易于重用，將 URL 路徑作為 prop 傳遞給自定義 Hook，并將其傳遞給 fetchData() 函數。

表示層

表示層應該包含負責呈現數據和響應 React 應用程序中的用戶操作的所有 UI 組件。這些組件中不應有業務邏輯或數據獲取代碼。

查看下面的 UserProfile 組件示例。

import React from "react";
import useUserData from "./customHooks/useUserData";


const UserProfile = () => {
  const [userData] = useUserData();
  return (
    <div>
      {userData.id ? (
        <div>
          <ul> {userData.name} </ul>
          <ul> {userData.email} </ul>
        </div>
      ) : (
        <p>Loading data...</p>
      )}
    </div>
  );
}


export default UserProfile;

組件中使用useUserData()自定義Hook與業務邏輯層通信，獲取用戶數據展示給用戶。除了返回函數，唯一應該包含在 UI 組件中的是業務邏輯層的函數調用，如本例所示。

這為您提供了清晰干凈的 UI 組件，使查找和修復與 UI 相關的錯誤變得更加容易。下面的存儲庫鏈接將帶您到完整的 React 分層架構示例項目。

GitHub：https://github.com/Manusha17/layered-architecture-example-project

使用分層架構時要避免的錯誤

• 過度工程——保持簡單且可擴展的架構，避免使用不遵循 React 模式的設計，例如基于繼承的設計。
• 緊耦合——當層緊密耦合時，在不影響其他層的情況下更改一個層可能很困難。通過使用適當的模式和技術（例如依賴注入和接口）來減少耦合。
• 忽略性能——如果實施不當，分層架構會影響應用程序性能。在優化架構以提高性能時，請考慮代碼拆分、延遲加載和緩存等因素。
• 糟糕的命名約定——為你的層、組件和函數使用清晰一致的命名約定。否則，從長遠來看，開發人員將很難理解和維護代碼。
• 缺乏測試——每一層都應該進行徹底的測試，以確保它按預期工作。未能測試每一層可能會導致最終應用程序中出現錯誤和其他問題。
• 缺乏凝聚力——每一層都具有高度的凝聚力。內聚性是指一個層內的功能和職責的相關程度。低內聚性會導致代碼難以理解和維護。

結論

作為 Web 開發框架，React 不強制執行特定的架構。因此，開發人員有責任選擇合適的體系結構，從長遠來看可以提高代碼的可維護性。本文探討了使用分層架構來創建高度可維護的 React 組件，以及我們應該避免的常見錯誤有哪些。

我希望本文能幫助您使用分層架構構建維護良好的可擴展 React 應用程序。

感謝您的閱讀。