我发布了几个问题,但还没有得到任何答复.我在这里陈述的所有内容都涉及JSF 2.0.*.
典型的bean包含要在页面上显示的信息.基于Web的通用业务应用程序是一组页面,其中每个页面都包含由多个xhtml页面表示的视图编辑保存状态.所以我们创建一个bean来管理这些状态.但是我将很快描述几个问题:
1)每个页面都是不同的视图,因此强制您将bean放入会话范围.它会使会话存储膨胀.
2)在视图之间传递参数.为了编辑文档,应该知道文档的ID或/和另一组对象.将它们放入会话中并不是一个好的决定(膨胀的会话反模式).
到目前为止,已经尝试了几种纠正这种情况的尝试.
a)t:saveState.多年来它一直在发挥作用.但现在我们正在摆脱它.b)接缝谈话.在谈话结束的确切时刻,它已经施加了很多问题.超时不是一个容易设置的参数,因为我们不知道业务用户需要多长时间,例如,编辑文档.对我们来说不是解决方案.
c)CODI(未尝试)它似乎是一个很好的JSR 299实现,并且可以解决所有问题,但它几乎没有文件记录,并且,因为作为扩展,坚持WELD这是另一个框架,我们只是想使用JSF的所有功能.
d)弹簧网络流程.嗯,这是一个非常好的框架,大量记录,伟大的IOC容器,流量范围和它提供的所有其他好东西可以是一种补救措施.它解决了多重标签问题(这是我的措辞,所以请原谅我,如果不清楚我得到了什么).想象一下,我们有一个编辑页面和视图范围的bean,我们正在填写表单.如果用户在新选项卡中打开另一个页面,则会触发GET请求并且bean超出范围.Web流可以识别这样的问题,并在打开新选项卡时启动新流程.
(网络流程的延续)但它是单片的,将迫使我们重写整个项目.是的,我知道它支持JSF,我已经测试过了一段时间,看看它是否符合要求.它不是因为它的安全性.不幸的是,我们没有时间也没有资源从头开始构建新项目.
我们几乎没有解决方案.JSF是一个很好的框架,已经过广泛测试并在许多项目中使用.但是开发人员拒绝在其中加入CDI.
任何人都可以推荐使用单个bean编辑视图保存问题的任何解决方案吗？任何建筑建议都会有很大的帮助.非常感谢你提前.
首先:这是一个讨论而不是一个问题,所以永远不会有一个明确的"是"或"否"......除了客观论点(开发人员不喜欢它)总有优点和缺点;-)
无论如何,让我首先确定您的情况对于所有类型的Web应用程序都是非常常见的,并且您所描述的问题对于从架构角度考虑Web应用程序开发的每个人来说更为常见.
面对一年前几乎完全相同的情况,这是我们的架构:
带有JSF 2.0的Java EE 6,CDI(+ EJB 3和JPA,但这超出了本答案的范围).
所有这些都像魅力一样,层之间几乎没有胶水代码.
1)每个页面都是不同的视图,因此强制您将bean放入会话范围.它会使会话存储膨胀.
2)在视图之间传递参数.为了编辑文档,应该知道文档的ID或/和另一组对象.将它们放入会话中并不是一个好的决定(膨胀的会话反模式).
我绝对和你在一起.这就是我们使用对话的原因.
b)接缝谈话.在谈话结束的确切时刻,它已经施加了很多问题.超时不是一个容易设置的参数,因为我们不知道业务用户需要多长时间,例如,编辑文档.对我们来说不是解决方案.
有3年Seam 2/3生产经验,我向您保证,这绝对是可以管理的.谈话适合像手套一样使用,过了一段时间你不想再使用其他任何东西了.当然不是会议;-)
c)CODI(未尝试)它似乎是一个很好的JSR 299实现,并且可以解决所有问题,但它几乎没有文件记录,并且,因为作为扩展,坚持WELD这是另一个框架,我们只是想使用JSF的所有功能.
如果你想使用CODI,你不需要Weld,两者都是JSR 299实现.在撰写本文时,Weld更好地记录并更频繁地使用.我甚至不知道CODI是否是最终的？
d)弹簧网络流程.嗯,这是一个非常好的框架,大量记录,伟大的IOC容器,流量范围和它提供的所有其他好东西可以是一种补救措施.它解决了多重标签问题(这是我的措辞,所以请原谅我,如果不清楚我得到了什么).想象一下,我们有一个编辑页面和视图范围的bean,我们正在填写表单.如果用户在新选项卡中打开另一个页面,则会触发GET请求并且bean超出范围.Web流可以识别这样的问题,并在打开新选项卡时启动新流程.
多标签问题也由Seam/Weld/CODI解决.那是九十年代......
我们几乎没有解决方案.JSF是一个很好的框架,已经过广泛测试并在许多项目中使用.但是开发人员拒绝在其中加入CDI.
JSF的问题在于您的项目不是绿地.您需要连接到后端,使用纯JSF范围和技术时,您将遇到问题.
我只能告诉你:我也必须说服我的同事使用CDI.我用所描述的布局中的工作原型做到了,现在,一年后,团队中的每个人都对我们的技术堆栈非常满意... :-)
总结这个相当冗长的答案:
Java EE 6是用于此类应用程序的出色技术堆栈,您应该尝试一下.您所描述的问题不仅可以通过Java EE 6解决,而是规范团队在设计API时所考虑的问题.
如果您愿意,请随时发布更多问题/疑问.