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

Question

在struts 1.x中使用具有会话范围的表单bean有哪些主要缺点？

Answer 1

如果您的表单包含从复选框填充的属性，则需要实现reset()。您不需要使用请求范围的表单bean。

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

您不能使用相同表单的两个浏览器标签或框架，因为它们会互相走在脚趾上。

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

Answer 2

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

1. 臭名昭着的复选框（以及相应的布尔属性）。如果您正在处理持久对象（编辑某个实体的布尔属性），那么无论如何重置复选框都需要额外的代码。范围无关紧要，因为布尔属性是持久的（在请求之间不会自动清除）。

2. 当您处理复杂的持久对象（对象的层次结构，由Hibernate映射到一组相关的数据库表）时，通常您只是将持久对象嵌套到表单bean中，使用嵌套属性，例如<html:text property="purchase.client.name" />（当然，您可以为整个层次结构的每个属性在form-b​​ean中创建getter / setter，但这很繁琐，并且会使进一步的开发复杂化）。对于创建，您只需在form-b​​ean中创建新的空purchase对象，对于版本，您将从数据库加载现有purchase（编辑请求将包含您要更改的对象的某些标识符）。范围无关紧要。

3. 关于两个浏览器标签。使用AJAX请求会产生更重要和低估的问题，特别是当它们不是幂等且在时间上重叠时（浏览器发出更新请求1，然后请求更新2）虽然更新1在服务器上仍然处理 - 虽然它是非常奇怪的设计（我的意思是在一个会话中同时重叠更新请求来自一个用户）。是的，在这种情况下，您需要将不同请求中的数据分开。但是，你的action（如果我们讨论的是Struts 1）应该是线程安全的，你的业务逻辑应该准备好并发/冲突更新（解决同步问题，锁定对象） ，合并/覆盖/拒绝更新等）。如果您正在开发多用户应用程序，当两个不同的用户想要同时更改同一个对象时，也可能会发生这种情况。同样，与整个问题相比，bean范围并不重要。

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