拥抱声明式数据访问以尊重您作为开发人员的智慧

# Web 开发 # JavaScript # 编程 # 初学者

在软件开发领域，我们经常发现自己在两种范式之间左右为难：**命令式**和**声明式**。对于许多开发人员来说，命令式代码的吸引力在于它的简单性——只需逐步编写指令，您就能确切地知道计算机在做什么。然而，随着复杂性的增加，这种逐步方法会变成散布在代码库中的一团乱麻。相比之下，声明式方法旨在让您描述您想要什么，而不是如何获得它，从而让您摆脱微观管理细节。

在这篇文章中，我们并不是要证明声明式设计是“最佳”方法。相反，我们将探讨声明式设计如何创建一个尊重您作为开发人员的智慧的系统 - 让您能够优雅地扩展应用程序并以更少的认知开销进行维护。

命令式：一条详细说明之路

假设你正在构建一个小型应用程序来从各种 API 获取帖子和用户。命令式方法可能如下所示：

const axios = require('axios');

// Imperative approach: You write every step for every request
async function fetchAllPosts() {
    const response = await axios.get('https://jsonplaceholder.typicode.com/posts');
    return response.data;
}

async function fetchUsers() {
    const response = await axios.get('https://dummyjson.com/users');
    return response.data.users;
}

乍一看，这很简单——只需发出 GET 请求并返回数据。但是当复杂性逐渐增加时会发生什么？您可能需要：

不同模型的多个端点。

身份验证标头。

分页、过滤和复杂查询。

数据验证和模型之间的关系。

您很快就会发现自己在到处复制和粘贴代码、硬编码端点和标头，并手动管理错综复杂的逻辑。命令式风格开始让人感觉像是一件苦差事：你一遍又一遍地编写相同的指令，而且很容易忘记所有逻辑的位置。

声明式：意图和模式的世界

现在让我们看一个更具声明性的设计。您无需告诉系统获取每个资源，而是描述每个资源的样子、位置以及与其他资源的关系。然后，让灵活的适配器或管理器处理后台细节。

以下是一个例子：

class PostAdapter extends APIAdapter {
    static baseURL = 'https://jsonplaceholder.typicode.com/';
    static headers = {};
    static endpoint = 'posts';

    async *all(...args){
        // Insert custom business logic here (e.g., logging, pagination)
        return await super.all(...args)
    }
}

class UserAdapter extends APIAdapter {
    static baseURL = 'https://dummyjson.com/';
    static headers = {};
    static endpoint = 'users';
}

class CustomValidatedPost extends Post {
    static schema = {
        ...Post.schema,
        email: 'string',
        body: 'string',
        userId: 'number'
    };
    static adapter = PostAdapter;
}

class CustomUser extends User {
    static adapter = UserAdapter;

    async _post() {
        return await CustomValidatedPost.objects.query({ id: this.id });
    }
}

// Using the declared models and adapters:
const userIterator = await CustomUser.objects.all();
async function processNextUser() {
    const { value: user, done } = await userIterator.next();
    if (done) return;
    // Handle your user data here
}

乍一看，这可能看起来更复杂，因为我们有类、静态属性和适配器。但仔细看看：

无需到处硬编码 URL：基本 URL、端点和标头在类级别定义一次。该模型的任何请求都会自动使用这些默认值。

声明关系，而非强制关系：CustomUser 定义了一个 _post 方法，该方法返回与用户相关的帖子。这感觉就像是一个查询，而不是一堆命令式代码。你正在陈述你的意图：“我想要这个用户的帖子。”

轻松扩展和自定义：需要自定义逻辑来获取帖子？只需在 PostAdapter 中重写 all() 即可。通过使此逻辑成为默认行为的干净扩展，您可以减少意外破坏其他内容的机会。

换句话说，您正在构建一个读起来更像是一组声明而不是一组指令的系统。适配器和模型形成了一种其余代码可以依赖的模式，而不是一组随机的“axios.get()”调用。

真正的胜利：尊重开发人员的智力

为什么要付出这些努力？因为随着项目的发展，您不想浪费时间在命令式逻辑的雷区中摸索。声明式设计设定了期望：

当你看到 CustomUser.objects.all() 时，你立即知道它的含义：它返回所有 CustomUser 实例的迭代器。无需猜测。

当您声明 static adapter = UserAdapter; 时，您知道对 CustomUser 的任何数据操作都会在后台使用 UserAdapter。一致性和清晰度是内置的。

当您在模型上定义静态模式时，您可以相信系统知道如何验证或处理这些字段，而无需您再次编写重复的命令式代码。

这种方法尊重您作为开发人员的智慧。它不会强迫您回忆哪个端点属于哪个模型或标头在哪里定义。相反，它可以让您在更高的层次上思考：定义您的数据是什么样子以及它如何关联，然后让框架处理其余的事情。

不追求“最好”，而是追求可持续发展

我们并不是说使用适配器和静态字段的声明式方法普遍优于原始命令式代码。对于小脚本，`axios.get()` 可能就是您所需要的。但随着系统规模的扩大，声明式方法会创建一个 **可持续的环境**，其中更改不那么麻烦、功能更容易添加，并且整体复杂性得到妥善管理。

你可以说，这是关于构建一个系统，让你（开发人员）更像一个智能工程师，而不是指令的转录员。

结论

如果您习惯于手写每个步骤，声明式方法一开始可能会让您感到陌生。但是，一旦您体验到拥有一致模式、明确声明的端点以及可以整齐地添加自定义逻辑的地方的平静，就很难再回到命令式的蔓延了。

这并不是为了证明自己优越，而是为了提供一种对未来的自己更友善、更尊重你的时间、更符合你对数据和关系的看法的方法。你不必对每个请求进行微观管理，而是编写读起来像故事的代码，专注于你想要什么，而不是如何获得它的每个繁琐细节。

CLIS.CC

拥抱声明式数据访问以尊重您作为开发人员的智慧

命令式：一条详细说明之路

声明式：意图和模式的世界

真正的胜利：尊重开发人员的智力

不追求“最好”，而是追求可持续发展

结论