JavaEE6 DAO: Sollte es @Stateless oder @ApplicationScoped sein?

Question

Ich erstelle gerade eine EJB3-Datenzugriffsklasse für alle Datenbankvorgänge in meiner Java EE 6-Anwendung. Jetzt, da Java EE 6 die neue ApplicationScoped-Annotation bereitstellt, frage ich mich, welchen Status mein EJB haben sollte oder ob es zustandslos sein sollte.

Wäre es besser, wenn das DAO eine @Stateless Session Bean oder eine @ApplicationScoped Bean ist? Was ist mit @Singleton? Was sind die Unterschiede zwischen diesen Optionen im Zusammenhang mit einem DAO?

EDIT: Ich bin mit Glassfish 3.0.1 mit der vollen Java EE 6-Plattform

Answer 1

Whould es besser sein, die DAO lassen eine @Stateless Session Bean sein, oder ein @ApplicationScoped Bean ? Was ist mit @Singleton? Was sind die Unterschiede zwischen diesen Optionen im Zusammenhang mit einem DAO?

I Stateless Session Beans für DAOs NICHT verwenden würde: durch den Behälter

1. EJBs werden gepoolt so, wenn Sie N Instanzen pro Pool und Tausende von Tabellen haben, Sie gehen nur Ressourcen zu verschwenden (Nicht einmal die Kosten zur Bereitstellungszeit zu erwähnen).

2. Die Implementierung von DAOs als SLSB würde die EJB-Verkettung unterstützen, was aus Skalierbarkeitsgründen keine gute Praxis ist.

3. Ich würde die DAO-Ebene nicht an die EJB-API binden.

Die @Singleton in EJB 3.1 eingeführt Dinge ein bisschen besser machen könnte, aber ich würde DAOs als EJBs noch nicht umsetzen. Ich würde lieber CDI (und vielleicht ein benutzerdefiniertes Stereotyp, siehe this article zum Beispiel).

Oder ich würde DAOs überhaupt nicht verwenden. Der Entity Manager von JPA ist eine Implementierung des Domain Store Patterns und der Wrapping-Zugriff auf einen Domain Store in einem DAO fügt nicht viel hinzu.

Answer 2

@Pascal: Meiner Meinung nach ist meine DAO nicht "verantwortlich" für Transaktion oder Sicherheit, da der Container diese Dienste verwaltet. Ich notiere nur die Methoden in meinem DAO (nur aus Sicherheitsgründen, da Transaktionen automatisch verarbeitet werden). Sind Annotationen bereits "Verantwortung"?

Okay, so dass Sie mich über mein Design denken lassen. Ich hoffe, es ist okay und nicht zu weit vom Thema, aber vielleicht hilft es - das ist, wie ich JEE6 heute bin mit:

• JSF greift auf eine CDI Bean,
• die CDI Bean greift auf die DAO-EJB die macht die "Business-Logik"
• so derzeit meine einzige "Business-Logik" macht CRUD, später werde ich einige andere EJBs für kritische Aufgaben wie asynchrone Methoden oder Timer-Dienste hinzufügen.
• mein DAO ist generisch und verwendet die JPA2 Criteria Query für typsichere Abfragen (überhaupt keine Zeichenfolgen)
• Ich weiß, dass ich kein DAO für persist/update/remove brauche (zu einfach), aber ich brauche es für meine Fragen; also setze ich sie zusammen

Ist etwas falsch mit diesem Ansatz?

Answer 3

Nach einigen Umdenken scheint es, wie DAO eigentlich nicht der richtige Name für das, was ich tun wollte. Vielleicht ist es wirklich eine Fassade, wie Pascal sagte. Ich habe gerade das Netbeans Petstore-Beispiel gefunden - eine JavaEE6-Beispielanwendung, siehe here - wo sie eine ItemFacade haben, die für das Suchen/Erstellen/Entfernen von Entitäten aus der Datenbank zuständig ist. Es ist eine Stateless Session Bean. Sieht wie folgt aus:

@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 als Abschluss DAO meine DAO nenne ich nicht mehr, sondern nur zum Beispiel PersonEJB (ich glaube „PersonFacade“ falsch verstanden werden könnte) und machen es auch @Stateless, wie ich denke, Das Netbeans-Beispiel kann als gut entworfen betrachtet werden.