avaStatic Fabrik Muster mit EJB3 / JBoss

Question

Ich bin ziemlich neu in EJBs und Blas- Anwendungsserver wie JBoss, geschrieben und arbeitete mit Zweckstandalone-Java-Anwendungen für die meisten meine Karriere, mit begrenztem Einsatz von Java EE. Ich frage mich, über den besten Weg, um ein häufig verwendetes Entwurfsmuster zu EJB3 und JBoss anzupassen: die statischen Fabrik Muster. In der Tat ist dieser Artikel # 1 in Joshua Bloch Effective Java Buch (2. Auflage)

Ich bin derzeit mit der folgenden Fabrik arbeiten:

public class CredentialsProcessorFactory {
    private static final Log log = LogFactory.getLog(CredentialsProcessorFactory.class);
    private static Map<CredentialsType, CredentialsProcessor> PROCESSORS = 
        new HashMap<CredentialsType, CredentialsProcessor>();

    static {
        PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
    }

    private CredentialsProcessorFactory() {}

    public static CredentialsProcessor getProcessor(CredentialsType type) {
       CredentialsProcessor p = PROCESSORS.get(type);
       if(p == null)
           throw new IllegalArgumentException("No CredentialsProcessor registered for type " + type.toString());
       return p;
}

Doch in den Implementierungsklassen von CredentialsProcessor, benötige ich Ressourcen wie ein PersistenceContext injiziert, so dass ich die CredentialsProcessor Schnittstelle eine @Local Schnittstelle gemacht haben, und jeder der impl ist mit @Stateless markiert. Jetzt kann ich sie in JNDI nachschlagen und die injizierten Ressourcen.

Aber jetzt habe ich eine Trennung, weil ich nicht das Werk verwenden mehr. Mein erster Gedanke war die getProcessor(CredentialsType) Methode zu ändern, um eine JNDI-Suche und geben die SLSB Instanz zu tun, die erforderlich ist, aber dann muss ich konfigurieren und übergeben Sie den richtigen qualifizierten JNDI-Namen. Bevor ich diesen Weg gehen, wollte ich mehr Forschung auf anerkannten Praktiken tun.

Wie ist das Design-Muster in EJB3 behandelt / Java EE -?

Answer 1

Wenn Sie mit Fabriken und „echtem“ Java POJO Code anfangen zu spielen, müssen Sie im Grunde auf JNDI verlassen.

Die Dependency Injection funktioniert nur auf den verwalteten Komponenten eines EJB-Servers, und das ist im Grunde Servlets und EJBs.

Wenn Sie generische Java-Code Rede ist, die EJBs beziehen will, müssen sie die Ressourcen selbst über JNDI Lookup.

Das Beste, was zu tun ist, in diesem Fall ist nur eine Wrapper-Lookup-Klasse mit statischen Funktionen gefüllt schreiben Sie Ihre JNDI-Lookups zu tun, anstatt JNDI Aufruf direkt in jeder Implementierung. Und dann in Ihren Implementierungen verwenden das.

Das ist nur eine generische Gesamt Regel.

Nun, für Ihren speziellen Fall, darüber nachzudenken.

Sie haben:

static {
    PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
}

Das ist nicht anders aus:

static {
    PROCESSORS.put(CredentialsType.CSV, "java:comp/env/ejb/CSVCredentialProcessorSessionBean");
}

Dann in Ihrem getProcessor () Code:

Context c = new InitialContext();
return (CredentialsProcessor) c.lookup(PROCESSORS.get(type));

See, im Grunde genommen, wird der Code identisch ist, und Ihre Fabrik-Schnittstelle ist das gleiche für die Kunden.

Sie müssen „hard-Code“ der JNDI-Lookup-Schlüssel, aber du bist „harte Kodierung“ die Klassennamen jetzt sowieso, also wie ist das anders?

Es gibt einige mögliche Portabilität Bedenken über Behälter, dass jeder anders JNDI Identifikatoren zu wie scheint Namen für Bean zu verwenden. Die meisten davon können in der Bereitstellung gezwickt werden, aber wenn nicht, dann können Sie diese Schlüssel heraus in einer Konfigurationsdatei ziehen, oder was auch immer.

In Java EE 6 sind tragbare Namen garantiert. Wenn Sie nicht Container heute portieren, dann nicht darum kümmern, das überhaupt.

Also, im Grunde ist es nicht wirklich eine Trennung überhaupt.

Answer 2

Mit EJB3, Sie müssen in der Regel nicht JNDI-Lookups zu tun. EJB3 unterstützt Dependency Injection von EJBs und einige andere Arten von Ressourcen. Wenn Ihr Bean-Attribut mit @EJB kommentiert wird, so wird die Abhängigkeit automatisch durch den Behälter injiziert werden.

nicht mit einem JNDI-Lookup-Mittel tun Sie Ihre EJB wie ein POJO für Einheit Testzwecke testen. Sie können nur manuell injizieren Mock Implementierungen von Abhängigkeiten und Test sie, ohne sie in einen Behälter einsetzen zu müssen.