JavaEE6 DAO:应该是@Stateless还是@ApplicationScoped?

Ing*_*her 20 java ejb java-ee java-ee-6 ejb-3.1

我目前正在创建一个EJB3数据访问类来处理我的Java EE 6应用程序中的所有数据库操作.现在,由于Java EE 6提供了新的ApplicationScoped注释,我想知道我的EJB应该具有什么状态,或者它应该是无状态的.

让DAO成为@Stateless会话Bean或@ApplicationScopedBean 会更好吗?怎么样@Singleton?这些与DAO相关的选项有何不同?

编辑: 我正在使用Glassfish 3.0.1与完整的Java EE 6平台

Pas*_*ent 15

让DAO成为@Stateless会话Bean或@ApplicationScoped Bean会更好吗?@Singleton怎么样?这些与DAO相关的选项有何不同?

我不会将无状态会话Bean用于DAO:

  1. EJB由容器池化,因此如果每个池有N个实例和数千个表,那么你只会浪费资源(甚至不会提到部署时的成本).

  2. 将SLO实现为SLSB将鼓励EJB链接,从可扩展性的角度来看,这不是一个好的做法.

  3. 我不会将DAO层绑定到EJB API.

@Singleton在EJB 3.1中引入可以让事情更好一点,但我仍然不会实现的DAO作为EJB的.我宁愿使用CDI(也许是一个自定义的刻板印象,例如参见这篇文章).

或者我根本不会使用DAO.JPA的实体管理器是域存储模式的实现,并且在DAO中对域存储的包装访问不会增加太多价值.

  • >`EJB由容器池化,因此如果每个池有数N个实例和数千个表 - 1.如果你有数千个表和数千个实体,你可能需要修改你的设计.除此之外,EJB实例通常是按需创建的,而不是事先创建的,当然也不是一次性创建完整的池容量.然后,即使创建了数千个实例,数千个实例的内存需求也只有一兆字节,这是完全无关紧要的.启动应用服务器时需要支付一小笔额外费用(我所说的是部署时间的意思) (7认同)
  • >`在DAO中包装对域存储的访问不会增加太多价值 - 对于纯粹的CRUD,实体管理器几乎*可以直接使用,但实际上DAO在您需要设置创建/最后修改字段时仍然提供值在保存/更新中.对于删除,您将必要的样板代码放在DAO中,因为实体管理器无法删除未附加的实体.此外,DAO可以包含对相关实体的查询的访问权限(服务执行相同的操作,但另外执行访问检查,DAO不执行) (7认同)
  • 2.为什么DAO鼓励"链接"??? 在这种情况下,这甚至意味着什么?如果你的意思是一个bean调用另一个bean,那么这在EJB中实际上是非常有效的(只要我们讨论本地调用,这当然应该在这里使用).注入非常便宜(注入代理),并且对其他bean的调用显式共享上下文资源,除非明确禁用(这是非常罕见的). (5认同)
  • 这显然是你的意见,但我其实绝对会这样做.它为您提供了轻松注入实体管理器的好处,并且这些方法可以自动创建或加入现有事务. (5认同)
  • 谢谢回复!我不想在这里讨论 DAO 是否有意义。对我来说,使用一个是有意义的。至少在 Seam 3 持久性模块准备好投入生产之前;)所以你说我不应该将 DAO 层绑定到 EJB API。但交易和安全呢?如果不是用于数据库操作 -> DAO,我会在哪里使用这些服务?这些服务不是由 CDI 提供的,至少不是像常规 JavaEE6 容器那样管理的。或者也许我应该混合使用 CDI 和 EJB? (2认同)