价值堆栈中会话持久性与维护之间的差异
我需要在 Struts 2 应用程序中的多个请求中保留一个对象。将对象放入 Session 中还是将其维护在 Struts 2 的 Value Stack 上更好？
那么，在会话中保留对象与在值堆栈上维护对象之间是否存在真正的区别（性能或其他方面）？
1) 会话
mutableSDO = getSession().get(SESSION_OBJ_IDENTIFIER);
// manipulate object
getSession().put(SESSION_OBJ_IDENTIFIER, mutableSDO);
2 ）在价值堆栈中维护
<s:property name="mutableDTO"/>
...
// mutableDTO instance variable set by Struts 2, value from client submit action
// mainpulate mutableDTO
this.mutableDTO = changedDTO;
// jsp uses changed DTO
...
<s:property name="mutableDTO"/>
I need to persist an object over multiple requests in my Struts 2 application. Is it better to put the object into Session or maintain it on Struts 2's Value Stack?
So, is there a real difference (performance or otherwise) between persisting an object in the session vs. maintaining the object on the Value Stack?
1) Session
mutableSDO = getSession().get(SESSION_OBJ_IDENTIFIER);
// manipulate object
getSession().put(SESSION_OBJ_IDENTIFIER, mutableSDO);
2) Maintain in value stack
<s:property name="mutableDTO"/>
...
// mutableDTO instance variable set by Struts 2, value from client submit action
// mainpulate mutableDTO
this.mutableDTO = changedDTO;
// jsp uses changed DTO
...
<s:property name="mutableDTO"/>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在S2应用程序中，会话、请求和参数都是值栈的一部分。
默认情况下，请求范围是公开的，但您需要 # 才能访问其他范围。
如果您为属性添加 # 前缀，它将按照它们出现的顺序访问上述范围，直到找到该属性。如果多个同名属性出现在范围堆栈中，您将需要使用 #scope_name.attr 显式查找所需的范围。
在选项 1 和选项 2 之间。只有选项 1 会在多个请求（实际上是维护会话的所有请求）中持续存在。第二个除了一个请求之外的任何时间都不会维护该值，而是将其从一个请求转发到下一个请求。第一个将允许用户随机访问应用程序中的任何页面并能够访问存储的值，第二个取决于转发到正确的页面。
假设您已经填充了员工表并想要转到员工的详细信息页面，则您应该只在请求范围内包含员工 ID。即使您需要多次使用 emp_id，也不应该将其包含在会话范围内。因此，如果您正在向前链接并掌握数据，那么这就是正确的方法。
如果您有一些用户偏好，例如背景颜色。那么将其放入会话值中将是一件好事，因为组或所有页面都会使用它。
主要考虑的是，如果用户打开多个窗口并点击刷新按钮，网站的行为是否会按预期运行？考虑用户打开多个员工详细信息窗口，如果该值作为会话值加载而不是作为 get 参数传递（位于请求范围内），则用户点击刷新以查看每个窗口上的最新员工数据只会获得最后一个员工加载到会话中。
In S2 application, session, request, and parameters are all part the value stack.
Request scope is exposed by default but you need # to access the other scopes.
If you prefix an attribute with # it will access the aforementioned scopes in the order they appear until the attribute is found. It multiple attributes of the same name appear in the stack of scopes you will need to explicitly look up the required scope with #scope_name.attr.
Between your option 1 and option 2. Only option 1 will persist over multiple requests (actually all requests that maintain a session). The second does not maintain the value over any time but one request, bubbling it forward from one request to the next. The first will let a user go to any page in your application randomly and be able to access the sored value, the second depends on forwarding to the correct pages.
Say you have populated a table of employees and want to go to a details page of the employee, you should only have the employee id in request scope. Even if you need to use emp_id multiple times you should not have it in session scope. So if you are chaining forward and have the data in hand this is the right way to go.
If you have some user preferences say, backgroud color. Then this would be a fine thing to put into a session value because a group or all pages will use it.
The main consideration is if the user opens multiple windows and hits the refresh button, will the site behave as expected? Consider a user opening multiple employee details windows, if the value were loaded as a session value instead of passed as get parameters (which are in the request scope), a user hitting refresh to see the latest employee data on each window would only get the last employee loaded on the session.