我尝试过 nestjs，但我意识到它因为有太多的装饰器而降低了代码的可读性，请花点时间访问这个

Question

我最近使用了 nestjs，但我意识到它过于复杂，我的意思是看下面的代码：

@post('/products')
getAllProducts(@Body('title') title, @Body('price') price, @Body('description') description) { }

它使函数参数变得很脏，而且函数上方可能还有更多装饰器，如@Header、@Params 等。在我看来，这会降低可读性。nodejs中的相同代码

const { title: title, price: price, description: description } = req.body

nodejs 更具可读性...

然后我研究了为什么开发人员使用 nestjs，原因是模块化。为什么我们不自己实现这个......

见下文：

查看我的目录结构

在 app.js 中，我刚刚踢了应用程序：

const express = require('express');

const app = express();

// express config
require('./startup/config')(app);

// handling routes
require('./startup/routes')(app);

// db setup
require('./startup/db')(app);

在启动文件夹中，我做了一些基本的工作，比如 mongoose 配置和连接到 db 等。

但是，在启动/路由中，我只是按如下方式踢了模块：

const shopModule = require('../shop/shop.module');

module.exports = app => {
    app.use('/', shopModule);
};

在商店模块中，我只是踢了如下路线：

const router = require('express').Router();

const productsRouter = require('./products/index');
const cartRouter = require('./cart/index');

// Products
router.use('/products', productsRouter)
// Cart
router.use('/cart', cartRouter)

module.exports = router;

现在在cart/index.js 中，我处理了与cart 相关的路由，并且与以下产品相同（我将只显示cart）：

const router = require('express').Router();

const { getCart } = require('./cart.controller');

router.get('/', getCart);

module.exports = router;

在控制器中，基本上我们会做验证等或提取数据..然后控制器将为数据库工作踢服务..

const { userCart } = require('./cart.service');

exports.getCart = (req, res, next) => {
    const cart = userCart();
    return res.status(200).json(cart);
};

最后在购物车服务中：

exports.userCart = _ => {
    // ... go to database and fetch cart
    return [{ prodId: 123, quantity: 2 }];
};

而cart.model.js 负责数据库架构，

我知道这个问题太长了，但我想解释一下我的问题。

我不是说不应该使用 nestjs，我只是说，下面的结构怎么样，因为它遵循与 angular 或 nestjs 相同的模式，对吗？

Answer 1

关于使代码更具可读性的第一点，为什么不做类似的事情

@Post('/products')
getAllProducts(@Body() body: any) {}

而不是单独调用身体的每个部分，那么你可以像你展示的那样解构身体

const {title: title, price: price, description: description} = body;

无需将身体的每个部分都指定为新参数，只需抓取对象本身即可。这同样也适用于@Header()，@Param()和@Query()。

至于你如何设置你的快递应用程序，你可以这样做是完全正确的；但是，如果您正在从事开源项目，或者与其他开发人员合作，则没有任何内容表明他们必须遵循相同的格式，并且最终可能会导致代码库混乱。Nest 强制执行这些模式，类似于 Angular 的做法。当然，编写糟糕的代码仍然是可能的，但是使用固执己见的架构确实会让它变得更加困难。

NestJS 也将 Typescript 视为一等公民，这在我看来也有助于摆脱很多开发问题。此外，您还可以使用一些非常酷的包，class-validator并class-transformer通过管道帮助验证和转换您的请求。你可以用 Typescript 写一个 Express 服务器，但这不是必需的，你可以用 JavaScript 写一个 NestJS 服务器，但我认为如果你这样做，你会失去很多好的功能。

最后一点，我认为并没有受到太多影响，Nest 通过它的模块为您的代码处理了很多黑盒。如果为模块定义服务，则它仅可用于该模块。如果您在另一个模块中需要它，您可以选择，但它有助于减少代码的交叉污染并牢记关注点分离的思想。

在我看来，NestJS 为我们提供了用于身份验证（保护）、验证和转换（管道和拦截器）以及错误处理（异常过滤器）等指定文件的事实使任何人都可以更轻松地选择 NestJS 服务器并拥有一个快速了解请求将如何流经服务器，即使仅查看文件结构。我个人知道如果我看到一个AuthModule或一个guards文件夹，我将在某种程度上处理身份验证。

回答您的最后一个问题：您显示 express 示例的方式没有任何问题，尤其是当您通过将 传递app到路由器以使其以这种方式工作来使用控制反转时，您绝对可以以这种方式编写 Express 服务器。Nest 只是让您这样做。（我的意思是，您可以仅使用AppController,AppService和编写整个服务器AppModule，但这确实是一种反模式）

最后，一定要使用你喜欢的东西，但最近 Nest 变得如此受欢迎是有原因的。