在软件开发的世界中，我们经常发现自己在两种范式之间左右为难：命令式和声明式。对于许多开发人员来说，命令式代码的吸引力在于它的简单性——只需逐步编写指令，您就可以确切地知道计算机在做什么。然而，随着复杂性的增加，这种循序渐进的方法变成了分散在代码库中的混乱的逻辑。相比之下，声明式方法旨在让您描述您想要什么，而不是如何获得它，从而将您从微观管理细节中解放出来。
在这篇文章中，我们并不是要证明声明式是“最佳”方法。相反，我们将探索声明式设计如何创建一个尊重您作为开发人员的智慧的系统，使您能够优雅地扩展您的应用程序并以少得多的认知开销来维护它。
势在必行：详细说明之路
假设您正在构建一个小型应用程序来从各种 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() 可能就满足您的需要。但随着系统规模的扩大，声明式方法会创建一个可持续的环境，其中更改不会那么痛苦，功能更容易添加，并且总体复杂性得到妥善管理。
你可以说这是关于构建一个系统，让你（开发人员）更像是一个聪明的工程师，而不是一个指令转录员。
结论
如果您习惯于手写每一步，那么声明式方法一开始可能会感觉很陌生。但是，一旦您体验到拥有一致的模式、明确声明的端点以及整齐地添加自定义逻辑的位置的平静，就很难再回到命令式蔓延。
这不是为了证明优越性。这是为了提供一种对未来的自己更友善、更尊重你的时间、更符合你对数据和关系的看法的方法。您不必对每个请求进行微观管理，而是编写读起来像故事一样的代码，专注于您想要的什么，而不是如何获得它的每个乏味细节。
