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

Question

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 ApplicationScoped 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 @Stateless Session Bean, or an @ApplicationScoped Bean? What about @Singleton? 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

Solution 1

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?

I would NOT use Stateless Session Beans for DAOs:

1. 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).

2. Implementing DAOs as SLSB would encourage EJB chaining which is not a good practice from a scalability point of view.

3. I would not tie the DAO layer to the EJB API.

The @Singleton 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 this article for example).

Or I wouldn't use DAOs at all. JPA's entity manager is an implementation of the Domain Store pattern and wrapping access to a Domain Store in a DAO doesn't add much value.

Solution 2

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 here - 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:

@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() { ... }
}

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.

Comments

[Wolkenarchitekt]

Thanks for the reply! I don't want to discuss here if a DAO makes sense. For me it makes sense to use one. At least until the Seam 3 Persistence Module is ready for production ;) So you say that i should not tie the DAO layer to the EJB API. But what about transactions and security? Where would i use those services, if not for database operations -> DAO? These services aren't provided by CDI, at least not the way like the regular JavaEE6-container manages then. Or maybe i should mix CDI and EJB?

[Devanshu Mevada]

@ifischer: DAOs should certainly NOT be responsible of transaction control and demarcation (or security), use a SLSB (a Session Facade) for that. So, yes, use EJB and CDI.

[Devanshu Mevada]

Which is the last part of my answer: no DAO at all and a session facade for transaction control and security, a SLSB being the natural candidate in Java EE. Now, I have to say that first, the above answer actually doesn't answer your initial question and second, (virtually) rewording your own question to match your answer doesn't motivate me to spend more time on this. Good luck anyway.

[Wolkenarchitekt]

Changed accepted answer. You're happy now? ;) You're right, this answer has nothing to do with my initial answer. Thanks for your help.

[Arjan Tijms]

>EJBs are pooled by the container so if you have N instances per pool and thousands of tables - 1. If you have thousands of tables, and thousands of entities you may need to revise your design. Besides that, EJB instances are typically created on demand and not beforehand and certainly not for the full pool capacity all at once. Then, even if thousands of them would be created, the memory requirements of thousands of instances is barely one megabyte, which is completely insignificant. There's a small extra cost when starting up the app server (which I take is what you mean with deploy time)

[Arjan Tijms]

2. Why do DAOs encourage "chaining"??? What does that even means in this context? If you mean that one bean calls the other, then this is actually quite efficient in EJB (as long as we're talking about local calls, which is of course what should be used here). Injections are very cheap (proxies are injected), and calls to other beans explicitly share contextual resources unless this is explicitly disabled (which is very rare to do).

[Arjan Tijms]

3. It's your opinion obviously, but I actually absolutely would do. It gives you the benefits of easily injecting an entitymanager and the methods automatically create or join an existing transaction.

[Arjan Tijms]

>wrapping access to a Domain Store in a DAO doesn't add much value - For purely CRUD the entity manager is almost directly useable, but in practice a DAO still provides value when you need to set created/last modified fields in save/update. For delete you put the necessary boilerplate code in the DAO, since the entity manager is not able to delete unattached entities. Furthermore, the DAO can contain access to queries for the entity in question (a service does the same thing, but additionally does access checks, a DAO does not)

[Ced]

@ArjanTijms This question and answers is a bit of a mess. OP not being sure of what dao is and two big rep guys not agreeing at all.Can you like confirm ifisher's answer is what you would do ? Seems like it is: stackoverflow.com/questions/30639785/…