在 Scala/Lift 中组织会话变量
想要了解如何在 scala / lift 应用程序中最好地组织会话变量的一些想法。
我在线阅读了许多 scala 材料，并在引入会话变量的所有示例中发现了以下范式：
- 声明一个扩展 SessionVar 类的对象，
- 将该对象放入包含片段（或任何文件）
- 访问 的文件中从代码库中的任何位置获取该对象（lift 将根据用户的 http 会话的生命周期处理会话变量的生命周期）
也许我不理解某些内容，但我担心这种方法会导致一大堆这些对象在不同的文件中到处都是。如果它是一个小应用程序，这没什么大不了的，但当项目变得更大时，这可能会导致混乱。
对于那些从事过大型 Scala 项目的人来说，是否有一种普遍接受的更好方法？ （即使它很简单，比如将所有这些对象放入一个公共文件中？）
谢谢。
Would like to get some thoughts on how to best organize session vars within a scala / lift application.
I've read over a number of scala materials online and have found generally the following paradigm in all examples that introduce session vars:
- declare an object that extends the SessionVar class
- put that object into a file that contains a snippet (or any file)
- access that object from anywhere in the codebase (lift will take care of the session var's lifecycle based on the lifetime of the user's http session)
Perhaps I'm not understanding something, but I'm concerned that this approach would lead to a whole bunch of these objects in various files all over the place. Its not such a big deal if its a small app, but when a project gets larger this could lead to chaos.
For those who have worked on larger scala projects, is there a generally accepted better approach? (even if its something simple like putting all of these objects into a common file?)
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这有点主观，但我会尝试一下。我认为这取决于会话变量在您的项目中的范围。
This is a bit subjective, but I'll give it a try. I think it depends on the scope the session var has in your project.
在您的应用程序中应谨慎使用 SessionVars。它们与 Servlet 会话变量类似，但它们是类型安全的。
您需要多少个会话变量？就我个人而言，我有一个当前用户主键的会话变量，也许还有一个或两个。应用程序的其余状态应存储在闭包中（因为与 GUID 关联的函数超出了范围）。
SessionVars should be used sparingly in your application. They are similar to Servlet Session Variables, except they are type safe.
How many session variables do you need? Personally, I have a session variable for the primary key of the current user and maybe one or two more. The rest of the state of the application should be stored in closures (because functions associated with GUIDs close over scope).