Session 在struts 1.x中定义具有会话范围的表单bean的缺点

在struts 1.x中使用会话范围的表单bean的主要缺点是什么？

如果表单包含从复选框填充的属性，则需要实现

reset（）

。您不需要它来请求作用域表单bean

如果第二次显示创建表单，则需要将表单重置为其默认值，否则创建表单将重新显示来自上次创建/更新对象的数据

不能有两个使用同一窗体的浏览器选项卡或框架，因为它们将相互依靠

---

默认情况下，表单bean应该在请求范围内。

只需尝试使用这两个范围，并为自己选择一个首选范围。但我应该说，当您使用持久对象（以及像Hibernate这样的ORM工具）时，有一点差别，这仅仅是因为属性在请求之间持久化在数据库中

臭名昭著的复选框（以及相应的布尔属性）。如果您使用的是持久对象（编辑某些实体的布尔属性），则需要额外的代码来重置复选框。作用域并不重要，因为布尔属性是持久的（不会在请求之间自动清除）

当您处理复杂的持久对象（对象的层次结构，由Hibernate映射到一组相关的数据库表上）时，通常只需将持久对象嵌套到表单bean中并使用嵌套属性，例如

（当然，您可以在表单bean中为整个层次结构的每个属性创建getter/setter，但这很繁琐，并且会使进一步的开发复杂化）。对于创建，您只需在表单bean中创建新的空

purchase

对象，对于版本，您将从数据库中加载现有的

purchase

（编辑请求将包含要更改的对象的某些标识符）。范围不再重要

关于两个浏览器选项卡。使用AJAX请求时会出现更重要且被低估的问题，尤其是当它们不是幂等项且在时间上重叠时（浏览器发出更新1请求，然后是更新2请求，而更新1仍在服务器上处理）-尽管这是一种非常奇怪的设计（我指的是一个用户在一个会话中同时重叠的更新请求）。是的，在这种情况下，您需要在不同的请求中分离数据。但是，您的

操作（如果我们谈论的是Struts 1）应该是线程安全的，并且您的业务逻辑应该准备好并发/冲突的更新（解决同步问题、锁定对象、合并/覆盖/拒绝更新等）。如果您正在开发多用户应用程序，当两个不同的用户希望同时更改同一个对象时，也可能发生这种情况。同样，bean范围与整个问题相比并不重要

---

正如您所看到的，会话范围的表单bean只有一个缺点，它只与严重的设计缺陷（来自一个用户的重叠更新请求）有关。

谢谢。我有一个两页的表单（第二个表单由json文本自动生成）。如果我不使用会话表单bean，我如何将bean传递到第二个页面？使用隐藏字段，或者通过将bean存储在会话中的UUID下，并将UUID作为隐藏字段传递。在第一种情况下，隐藏字段是否表示第二个表单bean的属性？是的，因为它是第二个表单bean，将使用s隐藏字段。我在将bean作为第二个表单bean的属性传递时遇到了一些问题。您能看看这个问题吗？