问API和路由器是两个独立的东西吗？

EN

你基本上已经重新发明了MVC设计模式。

并不是太复杂。这被认为是良好做法并受到鼓励。

C

传统上，您所称的路由器通常称为Controller。控制器的工作只是处理路由，处理参数解析(请求主体、查询参数、用户登录等)。有时还会处理验证。这正是Express设计的目的。而且Express允许将诸如身份验证和验证之类的控制器功能重构到中间件中。

注意:有时你会在互联网上看到教程，在那里人们会把控制器和路线分开。我个人的建议是，不做这个。快速路由被设计成非常适合写控制器。关于，将它们分开的唯一原因是如果您有两个不同的URL来完成完全相同的事情。在我看来，更好的办法是重定向。

我

传统上，您所称的API称为M模型。模型是您学习如何编程的对象或数据结构的传统集合。模型执行应用程序逻辑。通常，实现模型的类或模块不会使用任何标记。例如，用户模型不会被称为UserAPI或UserModel，而只是简单地称为User。然而，你所称的事情只是一个惯例。坚持对你来说有意义的事情。

V

MVC的最后一部分是View。在Express中，视图简单地是res.json()或res.render()及其关联的HTML模板。这个部分已经由Express开发人员编写了99% --您只需要告诉视图函数要发送什么到前端。

你的建筑很好

有很好的理由将模型(API)与控制器(路由器)分离。首先，它允许您在不使用参数解析逻辑污染核心逻辑的情况下解决问题。您的模型不需要担心用户是否登录或如何将数据传递给它。

其次，它允许您在Express之外使用模型(API)逻辑。这方面最明显的用途是单元测试。这允许您在没有代码的web部分的情况下对核心逻辑进行单元测试。我通常还编写实用程序脚本，用于创建新用户、转储用户数据、生成身份验证令牌，以便与Postman一起使用。

例如，您可以创建如下脚本：

#! /usr/bin/env node
// register-user.js

import UserAPI from '../api/v1/user.api.js'

UserAPI.registerUser({
    EMail: process.argv[2],
    Password: process.argv[4],
    Name: process.argv[3]
})
.then(x => {console.log(x); process.exit()})
.catch(console.error);

然后，您可以在命令行上执行该命令以创建新用户，而无需运行服务器：

$ ./register-user.js myemail@address.com 'My Name' 123456

看起来你的软件已经按照MVC设计好了。保持这种状态。这将使软件的维护和修改变得更加容易。

API和路由器是两种不同的东西，甚至来自不同的世界。

大多数应用程序由两个基本的构建块组成，即UI和API。UI应该是给人类的，API应该是机器的。您可以有0-n个UI和0-n个API。这是没有规则的。

例如，UI您可能有一个为普通访问者提供的网页，用于支付访问者的应用程序，或者为管理员购买您的产品和应用程序的应用程序。这是三个独立的UI。如果一个人出现故障，其他人也在工作。

另一个例子是API。每个UI都可以有不同的API。另外，还可以为第三方或您自己系统的其他微服务提供API。同样，如果一个API不起作用，它就不会影响其他API。

路由器是URL控制的设计模式。或者设计模式的具体实现，如果您愿意的话。

虽然UI和API可能都需要控制，但在应用程序系统的两个部分中都可以使用相同的模式。但这并不意味着它应该在同一个文件夹里。构建块的东西应该放在单独的文件夹中。与模型不同的是，路由器并不是在构建块之间共享的常见事物。

你在这里所呈现的文件夹结构，我相信你已经看到它的某个地方。但我不认为它很成熟。我会认为这样更成熟：

├── model
├── website-ui
│   ├── routers
│   ├── templates
│   └── index.js    // this is router
├── website-api
│   ├── user
│   │   └── index.js    // this might be a router (API dependent
│   ├── item
│   │   └── index.js    // this might be a router
│   └── index.js    // this is router
├── index.js
└── main-router.js    // this is router

通常，您甚至不会这样做main-router，因为这种责任通常是在Nodejs之外加载平衡器。但每个人都必须从某个地方开始。这个实现以后很容易升级。

不要将多个API与API版本混淆。在最好的情况下，您永远不需要API版本。你会这样做：

├── website-api
│   ├── user-old
│   │   └── index.js
│   ├── user
│   │   └── index.js
│   ├── item
│   │   └── index.js    
│   ├── index-v1.js
│   └── index-v2.js

或者说：

├── website-api-v1
│   ├── user
│   │   └── index.js
│   ├── item
│   │   └── index.js
│   └── index.js
├── website-api-v2
│   ├── user
│   │   └── index.js
│   ├── item
│   │   └── index.js
│   └── index.js

你现在说不出来了。你不应该在意。当您在API中进行更改时，您可以向后兼容它们。如果你不能再这样做，这意味着你已经做了一些重要的错误在过去，或大的业务变化出现。这是不可预测的。

拥有单独的api文件的好处之一是可恢复性。

是的，但你现在看不出来。

关于你的其他问题。坚持固体原则。代码的每个部分应该有一个特定的目的。

当我看到你的router文件夹时，我不知道那里是什么。我知道路由器，但是路由器的什么？什么都有，但什么也没有。因此不容易扩展=坏。

当我看我的结构时，我可以更容易地预测里面是什么。

您应该根据目的而不是特定的实现来设计您的体系结构。假设您有两个API，因为您有两个目的。他们都是REST还是GraphQL？我可以共享代码并删除重复吗？没那么重要。如果不正确地执行，共享代码实际上是非常危险的。共享代码是重构最糟糕的部分，而且它通常没有提供那么多的优点。

..。我开始怀疑我是否把它弄得太复杂了.

看情况，这是一个14天的项目吗？是的你做了。是一年还是更长时间？你应该走得更深。