所以,如果我的理解正确,您希望在控制器中避免大量这样的代码:
SomeModel.create({companyId: req.session.companyId, ...})
SomeModel.find({companyId: req.session.companyId, ...})
很公平。可能你担心companyId以后会被重命名,或者需要进一步处理。如果您使用自定义控制器操作,最简单的解决方案是为您的模型创建接受请求作为参数的类方法:
SomeModel.doCreate(req, ...);
SomeModel.doFind(req, ...);
另一方面,如果您在 v0.10.x 上并且可以将蓝图用于某些 CRUD 操作,您将受益于override the blueprints with your own code 的功能,因此您的所有创建和查找都会自动使用companyId 来自会话。
如果您来自非 Node 背景,这可能都会引起一些令人头疼的问题。 “为什么你不能让会话随处可用?”你可能会问。 “就像他们在 PHP 中所做的那样!”
原因是 PHP 是无状态——每个传入的请求本质上都是应用程序的一个新副本,内存中没有任何内容在请求之间共享。这意味着任何全局变量仅在单个请求的生命周期内有效。那个美妙的$_SESSION 哈希是你的,也是你自己的,一旦请求被处理,它就会消失。
与 Node 应用相比,后者本质上在单个进程中运行。您设置的任何全局变量都将在传入的每个请求之间共享,并且由于请求是异步处理的,因此无法保证一个请求会在另一个请求开始之前完成。所以很容易出现这样的情况:
- 请求 A 进来了。
- Sails 获取请求 A 的会话并将其存储在全局
$_SESSION 对象中。
- 请求 A 调用
SomeModel.find(),后者异步调用数据库
- 当数据库发挥作用时,请求 A 放弃了对节点线程的控制
- 请求 B 进来了。
- Sails 获取请求 B 的会话并将其存储在全局
$_SESSION 对象中。
- 请求 B 放弃对线程的控制以执行其他异步调用。
- 请求 A 返回其数据库调用的结果,并从
$_SESSION 对象中读取一些内容。
您可以在这里看到问题——请求 A 现在有错误的会话数据。这就是会话对象存在于请求对象中的原因,也是为什么需要将它传递给任何想要使用它的代码的原因。过分努力地规避这一点,必然会带来麻烦。