当我学习JSF2时,我意识到我不确定支持组件应该是什么.从设计的角度来看,EJB和@ManagedBeans？之间有什么区别？
最后我将使用JPA,因此EJB是业务层的自然选择.它是直接从JSF使用EJB一个很好的做法(如解释在这里)？
目前,我倾向于使用@ManagedBeans不需要访问业务层的组件(例如视图助手)或处理请求/会话数据.出于其他目的,例如在网格中列出某些内容,我将直接访问EJB.
这是一个很好的设计吗？@ManagedBeans为了清除层分离,我是否可以使用所有支持bean,即使在某些情况下它们只委托给EJB？
ewe*_*nli 13
非常有效的问题,但我想答案取决于项目方法的"严格性".JSF支持bean和EJB之间确实存在一些冗余,因为它们都实现了一些业务逻辑.
在一个理想的 JSF的使用与功能converters,rendered,validator等的支持bean 可能确实是干净的业务逻辑代码.但在实践中,一些与表示相关的逻辑经常泄漏.
理想情况下,这种与表示相关的逻辑应该不在EJB中.该表示相关逻辑可以取决于面包,但不是必需的.它是什么让它与演示相关或不相关.
统一组件模型虽然有一些优点.这是Seam和Spring采用的方法.在这两种情况下,具有声明性事务的业务组件等都可以直接在JSF中使用(Spring不使用EJB但提供类似的模型).然而,EJB纯粹主义者会说你应该分离这两者.
所以对我而言,这最终是一个关于项目品味和规模的问题.我可以想象,对于在JSF中使用EJB的小型/中型项目工作正常.对于严格要求严格的大型项目,请确保不要拧紧图层.
在Java EE 6中,各种托管bean之间存在一些重叠:JSF托管bean(@ManagedBean),CDI托管bean(@Named)和EJB bean(@Stateless,@ Statefull,@ Singleton).
在视图层中,我没有看到坚持@ManagedBean的任何特殊优势.CDI变体@Named似乎能够做同样的事情,例如,为您提供对转换范围的访问.
目前的想法似乎是,最终EJB组件模型也将作为一组CDI注释进行改进.特别是专家组成员Reza Rahman经常暗示这一点.请参阅例如Java EE 6中的依赖注入 - 第1部分
目前还没有发生这种情况,因此EJB bean仍然是放置业务逻辑的最简单的地方,尤其是当JPA用于持久性时.
然而,无论CDI是否将获得EJB的功能,恕我直言,对于"支持bean"概念使用单独的bean以及为"业务逻辑"使用单独的bean仍然是最佳实践.
支持bean可能非常简洁,只包含对模型对象和服务(EJB)的一些引用.操作支持bean的方法几乎可以直接委托给服务,但是它们的附加价值在于为用户提供反馈(成功或失败时添加FacesMessages)并进行小的UI修改(例如,将布尔值设置为false,显示一些对话框) .
服务(业务逻辑)不应该知道任何特定的演示文稿.它们应该同样适用于JSF支持bean,JAX-RS,Servlet,独立Java SE远程客户端或其他任何东西.
即使所有bean都成为CDI bean,这也不会改变这种基本的责任分工.