可维护性是我们在实际开发系统时，需要认真考虑的的一个重要方面。它决定了系统修改、修复和更新的难易程度。只有当所有组件都得到良好维护并且软件项目没有什么不同时，系统才会以最佳方式运行。

如果您的项目具有可维护高的良好架构，开发人员可以轻松了解项目并进行准确的更改以获得性能，同时缩短开发、测试和发布周期。

项目的架构是决定项目组件维护难易程度的关键因素。分层架构是为 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 应用程序。

感谢您的阅读。