blocks|key|3034037|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3034038|让DAO成为@无状态会话Bean或@ApplicationScoped+Bean会更好些吗？@Singleton怎么样？与DAO相关的这些选项之间有什么区别？|blockquote|3034039|3034040|3034041|我不会为DAOs使用无状态会话Beans：|3034042|3034043|EJB是由容器池化的，所以如果每个池有N个实例和数千个表，那么只会浪费资源(更不用说部署时的成本了)。|ordered-list-item|3034044|将DAO实现为SLSB会鼓励EJB链接，但从可伸缩性的角度来看，这不是一个好的做法。|3034045|我不会将DAO层绑定到EJB。|3034046|3034047|EJB3.1中引入的@Singleton可以让事情变得更好一些，但我仍然不会将DAOs实现为EJB。我更喜欢使用CDI+(也可能是一个自定义的构造型，比如this+article+)。|offset|length|style|CODE|3034048|否则我根本不会使用DAOs。JPA的实体管理器是Domain+Store模式的实现，在DAO中包装对域存储的访问不会增加太多价值。|3034049|entityMap|0|LINK|mutability|MUTABLE|url|http://www.theserverside.com/news/2240016831/Part-3-of-dependency-injection-in-Java-EE-6|1|http://www.corej2eepatterns.com/Patterns2ndEd/DomainStore.htm^0|0|0|0|0|0|0|0|0|0|0|A|A|25|C|0|0|O|C|1|0^^$0|@$1|2|3|-4|4|5|6|18|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|19|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1A|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1C|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1D|7|@]|8|@]|9|$]]|$1|I|3|J|4|K|6|1E|7|@]|8|@]|9|$]]|$1|L|3|M|4|K|6|1F|7|@]|8|@]|9|$]]|$1|N|3|O|4|K|6|1G|7|@]|8|@]|9|$]]|$1|P|3|-4|4|5|6|1H|7|@]|8|@]|9|$]]|$1|Q|3|R|4|5|6|1I|7|@$S|1J|T|1K|U|V]]|8|@$S|1L|T|1M|1|1N]]|9|$]]|$1|W|3|X|4|5|6|1O|7|@]|8|@$S|1P|T|1Q|1|1R]]|9|$]]|$1|Y|3|-4|4|5|6|1S|7|@]|8|@]|9|$]]]|Z|$10|$4|11|12|13|9|$14|15]]|16|$4|11|12|13|9|$14|17]]]]

<blockquote>
 Whould it be better to let the DAO be a @Stateless Session Bean, or an @ApplicationScoped Bean? What about @Singleton? What are the differences between these options related to a DAO? 
</blockquote>

I would NOT use Stateless Session Beans for DAOs:

<ol>
<li>EJBs are pooled by the container so if you have N instances per pool and thousands of tables, you're just going to waste resources (not even to mention the cost at deploy time). </li>
<li>Implementing DAOs as SLSB would encourage EJB chaining which is not a good practice from a scalability point of view.</li>
<li>I would not tie the DAO layer to the EJB API.</li>
</ol>

The <code>@Singleton</code> introduced in EJB 3.1 could make things a bit better but I would still not implement DAOs as EJBs. I would rather use CDI (and maybe a custom stereotype, see <a href="http://www.theserverside.com/news/2240016831/Part-3-of-dependency-injection-in-Java-EE-6" rel="noreferrer">this article</a> for example).

Or I wouldn't use DAOs at all. JPA's entity manager is an implementation of the <a href="http://www.corej2eepatterns.com/Patterns2ndEd/DomainStore.htm" rel="noreferrer">Domain Store</a> pattern and wrapping access to a Domain Store in a DAO doesn't add much value.

blocks|key|305634|text|@Pascal:在我看来，我的DAO并不“负责”事务或安全性，因为容器管理这些服务。我只是在注释我的DAO中的方法(只是为了安全起见，因为事务是自动处理的)。注解已经是“责任”了吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|305635|好吧，你让我重新思考我的设计。希望这没问题，不要太离题，但这可能会有帮助--这就是我今天使用JEE6的方式：|305636|305637|JSF访问CDI+Bean，|unordered-list-item|305638|+CDI+Bean访问执行“业务逻辑”|305639|的DAO-EJB所以目前我唯一的“业务逻辑”是执行CRUD，稍后我将为关键任务添加一些其他EJB，如异步方法或计时器服务。|305640|我的DAO是泛型的，它使用JPA2+Criteria查询来执行类型安全查询(根本不需要字符串)|305641|我知道我不需要用于持久化/更新/删除(太简单)的DAO，但是我的查询需要它；所以我只是将它们放在一起|305642|305643|这种方法有什么问题吗？|305644|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|Z|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|10|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|11|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

@Pascal:
In my opinion my DAO isn't "responsible" of transaction or security, as the container manages these services. I'm just annotating the methods in my DAO (only for security, as transactions are handled automatically). Are annotations already "responsibility"?

Okay so you make me re-think about my design. Hope its okay and not too off-topic, but maybe it helps - this is how i'm using JEE6 today:

<ul>
<li>JSF accesses a CDI Bean, </li>
<li>the CDI Bean accesses the DAO-EJB which
does the "business logic" </li>
<li>so currently my only "business logic" is doing CRUD, later i'll add some other EJBs for critical tasks like asynchronous methods or Timer Services. </li>
<li>my DAO is generic and uses the JPA2 Criteria Query to do typesafe queries (no strings at all) </li>
<li>I know that i don't need a DAO for persist/update/remove (too simple), but i need it for my queries; so i just put them together</li>
</ul>

Is something wrong with that approach?

blocks|key|3248281|text|经过重新思考，似乎DAO实际上不是我想要做的事情的正确名称。也许，正如帕斯卡所说，这真的只是一种假象。我刚刚找到了Netbeans+Petstore示例-一个JavaEE6示例应用程序，请参见here+-他们有一个ItemFacade，负责从数据库中查找/创建/删除实体。它是一个无状态会话Bean。看起来像这样：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3248282|@Stateless
public+class+ItemFacade+implements+Serializable+{
++++@PersistenceContext(unitName+=+"catalogPU")
++++private+EntityManager+em;

++++public+void+create(Item+item)+{+...+}
++++public+void+edit(Item+item)+{+...+}
++++public+void+remove(Item+item)+{+...+}
++++public+Item+find(Object+id)+{+...+}
++++public+List<Item>+findAll()+{+...+}
++++public+List<Item>+findRange(int+maxResults,+int+firstResult)+{+...+}
++++public+int+getItemCount()+{+...+}
}|code-block|syntax|javascript|3248283|因此，作为结论，我不再将我的DAO命名为PersonEJB，而只是例如PersonEJB(我认为"PersonFacade“可能会被误解)，并将其设置为@Stateless，因为我认为Netbeans示例可以被认为是设计良好的。|3248284|entityMap|0|LINK|mutability|MUTABLE|url|http://weblogs.java.net/blog/caroljmcdonald/archive/2009/08/java_ee_6_pet_c.html^0|2O|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

After some rethinking, it seems like DAO is actually not the right name for what i wanted to do. Maybe it really is a Facade, as Pascal said. 
I just found the Netbeans Petstore Example - a JavaEE6 sample application, see <a href="http://weblogs.java.net/blog/caroljmcdonald/archive/2009/08/java_ee_6_pet_c.html" rel="nofollow noreferrer">here</a> - where they have an ItemFacade which is responsible for finding/createing/removing entities from the database. It's a Stateless Session Bean. Looks like this:

<pre><code>@Stateless
public class ItemFacade implements Serializable {
 @PersistenceContext(unitName = "catalogPU")
 private EntityManager em;

 public void create(Item item) { ... }
 public void edit(Item item) { ... }
 public void remove(Item item) { ... }
 public Item find(Object id) { ... }
 public List&lt;Item&gt; findAll() { ... }
 public List&lt;Item&gt; findRange(int maxResults, int firstResult) { ... }
 public int getItemCount() { ... }
}
</code></pre>

So as a conclusion i don't call my DAO DAO anymore but instead just for example PersonEJB (i think "PersonFacade" could be misunderstood) and make it also @Stateless, as i think the Netbeans example can be considered as well-designed.

I'm currently creating an EJB3 Data Access Class to handle all database operations in my Java EE 6-application. Now, since Java EE 6 provides the new <code>ApplicationScoped</code> annotation, I wonder what state my EJB should have, or if it should be stateless. 

Would it be better to let the DAO be a <code>@Stateless</code> Session Bean, or an <code>@ApplicationScoped</code> Bean? What about <code>@Singleton</code>? What are the differences between these options related to a DAO? 

EDIT:
I'm using Glassfish 3.0.1 with the full Java EE 6 platform

JavaEE6 DAO: Should it be @Stateless or @ApplicationScoped?

数据库

容器

我目前正在创建一个EJB3数据访问类来处理我的JavaEE6应用程序中的所有数据库操作。现在，由于JavaEE6提供了新的ApplicationScoped注释，我想知道我的EJB应该具有什么状态，或者它是否应该是无状态的。让DAO成为@Stateless会话Bean还是@ApplicationScoped Bean更...

问JavaEE6 DAO:应该是@无状态的还是@ApplicationScoped的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JavaEE6 DAO:应该是@无状态的还是@ApplicationScoped的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JavaEE6 DAO:应该是@无状态的还是@ApplicationScoped的？
EN