Spring 3 MVC：表单支持对象必须处于会话中？我怎样才能避免这种情况？

发布于 2024-12-15 05:08:49 字数 755 浏览 3 评论 0原文

我读了一些关于 Spring 3 MVC 中表单和提交的教程。所有这些示例都表明，通过以下方式将支持对象存储在会话中：

@SessionAttributes({"command"})

我使用旧版本的 Spring，其中如果控制器继承 SimpleFormController，则有一个 formBacking 方法。

protected Object formBackingObject(HttpServletRequest request)

如果我的理解是正确的，旧版本的方法会在表单提交时动态加载表单支持对象，并且不需要将此对象存储在会话中。

如果我对 Spring 3 MVC 的理解是正确的，那么我不喜欢会话方法，因为在大用户的情况下它会消耗大量内存，并且存储在会话中的对象在表单提交时可能会过时。

我可以避免在 Spring 3 的 MVC 中将表单支持对象存储在会话中吗？有什么指针吗？

感谢您的任何意见，如果我错了，请纠正我。

问候。

还有人知道我的理解对吗？

<块引用>
GET 控制器将对象添加到模型中相当于将其添加到会话中。当提交表单时，Spring 如何记住该对象作为支持对象？干杯。

当提交表单时，添加到 GET 控制器中的模型的表单支持对象如何能够在服务器和客户端之间的往返过程中幸存下来？ Spring是否将其序列化到磁盘上？我猜...

感谢您的任何意见！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

家住魔仙堡 2024-12-22 05:08:49

如果您只是不在 @SessionAttributes 中列出您的命令，那么它每次都会被实例化。

在旧的控制器 API 中，实现可以决定是否要在会话中保留命令对象：请参阅 AbstractFormController.isSessionForm()。 SimpleFormController 返回 false，而 AbstractWizardFormController 返回 true，因为它实际上需要将命令存储在会话中。

您可以在 HandlerMethodInvoker.resolveModelAttribute(...) 私有方法中检查模型属性是如何绑定的：

if (implicitModel.containsKey(name)) {
    // ...
} else if (this.methodResolver.isSessionAttribute(name, paramType)) {
    // ...
else {
    bindObject = BeanUtils.instantiateClass(paramType);
}

很明显，如果您没有明确地将其声明为会话属性，绑定器将使用新的实例;与从 AbstractFormController.isSessionForm() 返回 false 完全相同。

提交表单时，添加到 GET 控制器模型中的表单支持对象如何能够在服务器和客户端之间的往返过程中幸存下来？ Spring是否将其序列化到磁盘上？我猜...

Spring 并不（总是）需要在表单视图和表单提交之间存储支持对象。如果填充命令对象所需的一切都随请求一起提供，Spring 可以简单地实例化一个新的命令对象（无论是它本身还是让您在提供正确的方法的情况下执行此操作），然后将请求绑定到该新实例。

请参阅上面与旧 API 的比较，了解 SimpleFormController 和 AbstractWizardFormController 实现之间的差异。第一个不需要在会话中存储任何内容，它将提交请求绑定到新创建的对象。使用新的带注释的处理程序，流程是相同的；如果您不想存储它，它将在提交时重新创建：BeanUtils.instantiateClass(...) 或您自己的自定义工厂方法。

If you simply do not list your command among the @SessionAttributes, it will be instantiated every time.

In the old Controller API, implementations could decide whether or not they want to keep their command objects on the session: see AbstractFormController.isSessionForm(). SimpleFormController returned false, while AbstractWizardFormController returned true, as it actually required the command to be stored on the session.

You can check how a model attribute is bound in the HandlerMethodInvoker.resolveModelAttribute(...) private method:

if (implicitModel.containsKey(name)) {
    // ...
} else if (this.methodResolver.isSessionAttribute(name, paramType)) {
    // ...
else {
    bindObject = BeanUtils.instantiateClass(paramType);
}

So obviously, the binder will use a fresh instance if you don't explicitely declare it as session attribute; exactly the same as returning false from AbstractFormController.isSessionForm().

How can the form backing object added to the model in the GET controller survive a round trip between the server and client when a form is submitted? Does Spring serialize it on disk? I am guessing...

Spring does not (always) need to store the backing object between form view and form submission. If everything that you need in order to populate your command object comes with the request, Spring can simply instantiate a new command object (either itself or let you do it if you provide a proper method) and then bind the request to that fresh instance.

See above the comparison with the old API regarding the difference between SimpleFormController and AbstractWizardFormController implementations. The first does not need to store anything on the session and it will bind the submit request to a newly created object. With the new annotated handlers, the flow is the same; if you don't want to store it, it will be recreated on submit: BeanUtils.instantiateClass(...) or your own custom factory method.

回复收藏 0 原文