【问题标题】:node.js / express application - where do i put the database connection logic?node.js / express 应用程序 - 我将数据库连接逻辑放在哪里?
【发布时间】:2016-09-28 13:36:25
【问题描述】:

背景信息

我刚刚创建了我的第一个 express 应用程序。我可以看到它创建了一堆文件和默认文件夹结构。这是我的应用程序结构目前的样子:

me@mydevbox:/var/www/html/nodejs_samples/tutorial1$ ls -lah
total 36K
drwxr-xr-x  7 me me 4.0K Sep 28 09:26 .
drwxrwxr-x  5 me me 4.0K Sep 28 08:45 ..
-rw-rw-r--  1 me me 1.5K Sep 28 08:45 app.js
drwxr-xr-x  2 me me 4.0K Sep 28 09:20 bin
drwxrwxr-x 96 me me 4.0K Sep 28 09:26 node_modules
-rw-rw-r--  1 me me  352 Sep 28 09:26 package.json
drwxr-xr-x  5 me me 4.0K Sep 28 08:45 public
drwxr-xr-x  2 me me 4.0K Sep 28 09:26 routes
drwxr-xr-x  2 me me 4.0K Sep 28 08:45 views
me@mydevbox:/var/www/html/nodejs_samples/tutorial1$ 

目标

我想创建一个名为“widgets”的新路由,当调用 GET 方法时,我需要调用 redis 数据库并执行查询。 我想用来触发这个获取的 URL 是这样的:

  http://myserver/tutorial1/widgets/

  http://myserver/tutorial1/widgets/12345

其中 12345 是我要查询的小部件键。

到目前为止我做了什么

我找到了解释如何连接/查询 redis 数据库的文档:http://expressjs.com/en/guide/database-integration.html#redis

我还将 express 生成器为我“免费”创建的 routes/users.js 复制到 routes/widgets.js 作为起点。

这是我的 routes/widgets.js 文件的样子:

me@mydev:/var/www/html/nodejs_samples/tutorial1$ cat routes/widgets.js 
var express = require('express');
var router = express.Router();

/* GET widgets listing. */
router.get('/', function(req, res, next) {
  res.send('respond with a resource');
});

module.exports = router;

问题

我不清楚应该在哪里添加数据库连接逻辑和查询逻辑。我习惯于 MVC,您将所有数据库逻辑拆分到模型中。

我可以将所有内容都放在 route/widgets.js 文件中吗?

如果有帮助,这里是我的 app.js 文件的链接:http://pastebin.com/hAe5mvwt。我添加了 2 行 - 第 10 行和第 28 行。

任何好的教程的建议或链接将不胜感激。

【问题讨论】:

  • 可以,但是它直接耦合到路由处理程序。以这种方式开始很好,但我更喜欢更强的关注点分离。归根结底,这归结为意见:没有一种特定的“正确”方式来分解功能。

标签: javascript node.js model redis node-redis


【解决方案1】:

简短的回答是肯定的,MVC 运行良好,数据库内容当然可以进入模型。

但是,给猫剥皮的方法有很多。在这一点上有些微不足道的事情,我认为你应该做对你来说方便的事情,并且感觉像是一个相当干净的设计。

问题在于,随着您的系统变得越来越复杂,您需要一种方法来平稳地发展它。你永远不会拥有最终的“最佳”设计,因为现实会随着你的前进而改变。

请务必先查看 node-modules.com、npmjs.com、npms.io,以探索已经实现和流行的许多(并且非常多样化)强大的设计。

如果您有时间,我认为您应该探索多种不同的代码组织策略。

但更大的问题是,您如何在不完全破坏您的应用程序(并且不知道)的情况下更改此设计(您最终想要更改它)?

因此,我认为与其现在过多地为代码组织而苦恼,不如将精力花在想出尽可能多地自动测试代码的方法上。这样,当您更改设计时,您将能够看到损坏的地方 - 因此更改设计是可行的。

您需要在可行的情况下进行单元测试,否则需要集成测试,更大的案例端到端测试。

如果您可以将某些东西放入其自己的模块/模型文件/任何东西中并作为一个单元单独测试,那么这可能比其他设计更好。

【讨论】:

  • 我非常喜欢你的建议。将代码分成可测试的单元是我要牢记的一个很好的总体原则。我想我要做的就是首先将所有内容放入特定的路由文件中......只是为了学习节点和表达......然后一旦我熟悉它......也许戴上测试帽并重新访问我的示例代码,看看哪种重构最能支持测试。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2013-11-14
  • 1970-01-01
  • 2012-01-22
  • 2016-03-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多