为什么JSF在服务器上保存UI组件的状态？

为什么JSF需要保存服务器端UI组件的状态？因为HTTP是无状态的，JSF是有状态的。JSF组件树受动态(编程)更改的影响。JSF只需知道表单显示给Enduser时的确切状态，就可以在表单被提交回服务器时根据原始JSF组件树提供的信息成功地处理整个JSF生命周期。组件树提供有关请求参数名称、必要的转换器/验证器、绑定托管bean属性和操作方法的信息。在什么时候JSF在服务器端保存UI组件的状态，以及何时从服务器内存中确切地删除UI组件的状态信息？这两个问题似乎归结为同一个问题。无论如何，这是特定于实现的，也取决于状态是保存在服务器上还是客户端上。一个适当的实现将删除它时，它已过期或队列已满。例如，当状态保存设置为Session时，mojarra的默认限制为15个逻辑视图。中的以下上下文param可配置此web.xml:<context-param>     <param-name>com.sun.faces.numberOfLogicalViews</param-name>     <param-value>15</param-value></context-param>另见Mojarra常见问题对于其他mojarra特有的params和这个相关的答案com.sun.faces.number OfViewsInSession与com.sun.faces.number OfLogicalViews当应用程序上的登录用户通过页面导航时，组件的状态会在服务器上不断累积吗？从技术上讲，这取决于实现。如果您说的是逐页导航(只需要获取请求)，那么mojarra将不会在会话中保存任何内容。但是，如果它们是POST请求(带有命令链接/按钮的表单)，则mojarra将保存会话中每个表单的状态，直到达到最大值。这使Enduser能够在同一会话中的不同浏览器选项卡中打开多个窗体。或者，当状态保存设置为Client时，JSF将不会在会话中存储任何内容。您可以通过以下上下文param在web.xml:<context-param>     <param-name>javax.faces.STATE_SAVING_METHOD</param-name>     <param-value>client</param-value></context-param>然后，它将被序列化为具有名称的隐藏输入字段中的加密字符串。javax.faces.ViewState表格的。我不明白将UI组件的状态保持在服务器端的好处是什么。直接将经过验证/转换的数据传递给托管bean还不够吗？我能/应该尽量避免吗？这不足以确保JSF的完整性和健壮性。JSF是一个具有单个控制点的动态框架。如果没有状态管理，就可以某种方式欺骗/哈克HTTP请求(例如操作)。disabled, readonly和rendered(属性)，让JSF做不同的-也可能是危险的-的事情。它甚至容易受到CSRF攻击和网络钓鱼。如果有数千个并发用户会话，那么服务器端不会消耗太多内存吗？我有一个应用程序，用户可以在其中发布关于某些主题的博客。这个博客很大。当出现回发或请求查看博客时，大型博客将被保存为组件状态的一部分。这会消耗太多的内存。这不是个问题吗？记忆特别便宜。只要给应用服务器足够的内存。或者，如果网络带宽对您来说更便宜，只需将状态保存切换到客户端即可。要找到最佳匹配，只需压力和配置您的Webapp与预期的最大并发用户数量，然后给应用服务器125%~150%的最大测量内存。请注意，JSF2.0在状态管理方面有了很大改进。保存部分状态是可能的。只这个<h:form>将被拯救，而不是所有的东西<html>自始至终)。例如，莫扎拉就是这样做的。一个平均表单有10个输入字段(每个输入字段都有一个标签和消息)和2个按钮，所需时间不超过1KB。如果会话中有15个视图，则每个会话不应超过15 KB。对于~1000个并发用户会话，应该不超过15 MB。您应该更加关注会话或应用程序范围中的实际对象(托管bean，甚至DB实体)。我看到了很多代码和项目，它们不必要地将整个数据库表复制到Java的内存中，就像会话作用域bean一样，其中使用Java而不是SQL来过滤/分组/安排记录。如果有1000条记录，那就很容易超过10 MB每个用户会话.

为什么JSF在服务器上保存UI组件的状态？

更新1：

更新2：

3回答