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 JavaEE6-application. Now, since JavaEE6 provides the new ApplicationScoped-Annotation, i wonder what state my EJB should have, or if it should be stateless.

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?

EDIT: I'm using Glassfish 3.0.1 with the full JEE6 platform

Answer 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.

Answer 2

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

• JSF accesses a CDI Bean,
• the CDI Bean accesses the DAO-EJB which does the "business logic"
• 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.
• my DAO is generic and uses the JPA2 Criteria Query to do typesafe queries (no strings at all)
• 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

Is something wrong with that approach?

Answer 3

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.