1 回答

TA贡献1909条经验 获得超7个赞
javax.enterprise.context.SessionScoped
(JSR 346)和该javax.enterprise.context.*
软件包下的所有其他注释都维护CDI的上下文。CDI为Java EE空间中的依赖项注入,bean和常规资源管理提供了一种替代的,通用的,更强大的机制。它是JSF托管Bean的替代方法,它甚至可以在即将发布的JSF版本中取代JSF Bean管理机制。当前,在任何给定的Java EE Web应用程序中,JSF和CDI注释的bean都是可以互换的(有一些小的限制)。但是,带有CDI注释的Bean远远超出了Web层的范围,这就是Java EE规范不断发展以使CDI成为标准Bean和DI机制的原因。
尽管CDI对于所有Java EE开发来说都是显而易见的选择,但JSF托管bean可跨servlet容器(Tomcat)和应用程序服务器(Glassfish,JBoss等)移植。CDI bean只能存在于完整的应用程序服务器中。但是,通过一些工作,可以将Tomcat 7连接起来以支持CDI。
具体而言,
javax.enterprise.context.SessionScoped
是CDI中JSF会话范围的并行实现。javax.faces.bean.SessionScoped
(JSR 314)和该javax.faces.bean.*
包下的所有其他注释都维护特定于JSF的依赖项注入和bean管理机制。但是,使用JSF批注进行批注的Bean仅在Web层内有用。JSF批注提供的所有作用域已在CDI规范中复制。javax.annotation.ManagedBean
(JSR 316)和下面的其他与DI相关的注释javax.annotation.*
是对Java EE规范中其他用途的基于JSF的注释进行通用化的尝试,并且最终开发人员实际上不应使用。
它们为什么存在?IMO,从JSF bean到CDI bean的迁移是该技术的自然演进。JSF bean运行良好,但是像Spring,Guice和Seam这样的公司显然表明该技术还不够。还需要弥合Web组件和EJB之间的鸿沟,对此需求的响应是CDI。
添加回答
举报