Tapestry：会话状态对象何时应该优先于会话属性？答案

【问题标题】：Tapestry: When should a Session State Object be preferred to a Session Attribute?Tapestry：会话状态对象何时应该优先于会话属性？
【发布时间】：2015-08-27 01:28:24
【问题描述】：

从Tapestry doc我似乎明白了一个用@SessionAttribute注释的字段和一个用@SessionState注释的字段的工作方式相同，除了@SessionAttribute按名称存储值（名称可以是指定），这意味着可以存储同一类的不同实例，而@SessionState按类型存储值，因此存储同一类的不同实例将不起作用，新实例将始终覆盖旧实例（即使两个是不同的字段，具有不同的名称和来自不同的类）。

所以看起来@SessionState 并没有比@SessionAttribute 提供任何优势，只有限制，但我可能遗漏了一些东西。我无法弄清楚出于任何原因使用@SessionState 比@SessionAttribute 更可取的情况。

有这种情况吗？

【问题讨论】：

标签： session session-variables session-state tapestry

【解决方案1】：

@SessionAttribute 主要用于某些互操作情况，其中一些其他非 Tapestry 代码（另一个 servlet）期望使用明确指定的名称存储数据。

@SessionState 的优点是名称是根据类型自动确定的……少了一件需要关心的事情，并且更易于重构。

【讨论】：

谢谢，这回答了我的问题。 @SessionAttribute 主要用于某些互操作案例这一事实是否意味着在标准的非互操作案例中使用它而不是 @SessionState 可能存在缺点（除了必须关心设置名称之外）？比如性能、内存使用或其他？
我被要求为@SessionState 比@SessionAttribute 提供具体优势，我无法提及任何内容，而且我无法反驳@SessionState 自动确定名称的反对意见从类型来看，它既是一种优势，也是一种限制，这取决于使用上下文，因为这种所谓的优势也是无法存储多个实例的原因。实际上，至少现在我不得不同意这个反对意见。