фабричный шаблон avaStatic с EJB3 / JBoss - PullRequest
Новая
       11

фабричный шаблон avaStatic с EJB3 / JBoss

2 голосов
/ 30 марта 2010

Я довольно новичок в EJB и полнофункциональных серверах приложений, таких как JBoss, я писал и работал со специализированными автономными приложениями Java большую часть своей карьеры, с ограниченным использованием Java EE. Мне интересно, как лучше адаптировать часто используемые шаблоны проектирования для EJB3 и JBoss: статический шаблон фабрики. На самом деле это пункт № 1 в книге Джошуа Блоха «Эффективная Java» (2-е издание)

В настоящее время я работаю со следующей фабрикой: 

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;
}

Однако в классах реализации CredentialsProcessor мне требуются внедренные ресурсы, такие как PersistenceContext, поэтому я сделал интерфейс CredentialsProcessor интерфейсом @Local, и каждый импл отмечен @Stateless. Теперь я могу найти их в JNDI и использовать введенные ресурсы.

Но теперь у меня отключение, потому что я больше не пользуюсь фабрикой. Моей первой мыслью было изменить метод getProcessor(CredentialsType), чтобы он выполнял поиск JNDI и возвращал требуемый экземпляр SLSB, но затем мне нужно настроить и передать правильное квалифицированное имя JNDI. Прежде чем идти по этому пути, я хотел бы больше изучить принятые практики.

Как обрабатывается этот шаблон проектирования в EJB3 / Java EE? -

Ответы [ 2 ]

0 голосов
/ 30 марта 2010

Когда вы начинаете играть с фабриками и «настоящим» кодом Java POJO, вам в основном нужно полагаться на JNDI.

Внедрение зависимостей работает только на управляемых компонентах сервера EJB, и это в основном сервлеты и EJB.

Когда вы говорите об общем коде Java, который хочет ссылаться на EJB, им нужно самим искать ресурсы через JNDI.

В этом случае лучше всего написать класс поиска оболочки, заполненный статическими функциями, для выполнения поиска JNDI, а не вызывать JNDI непосредственно в каждой реализации. А затем используйте это в своих реализациях.

Это просто общее правило.

Теперь, для вашего конкретного случая, рассмотрим это.

У вас есть: 

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

Это ничем не отличается от: 

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

Затем в вашем коде getProcessor (): 

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

Видите ли, в основном код идентичен, и ваш заводской интерфейс такой же, как у клиентов.

Вы должны «жестко кодировать» ключ поиска JNDI, но вы все равно «жестко кодируете» имена классов, так как это отличается?

Существует некоторая потенциальная проблема переносимости между контейнерами, в которой всем, похоже, нравится использовать разные идентификаторы JNDI для имен бинов. Большая часть этого может быть изменена при развертывании, но если нет, то вы можете вытащить эти ключи в файл конфигурации или что-то еще.

В Java EE 6 есть гарантированные переносимые имена. Если вы сегодня не переносите контейнеры, тогда вообще не беспокойтесь об этом.

Так что, по сути, это вообще не отключение.

0 голосов
/ 30 марта 2010

С EJB3 вам обычно не нужно выполнять поиск JNDI. EJB3 поддерживает внедрение зависимостей EJB и некоторые другие типы ресурсов. Если ваш атрибут bean-компонента аннотирован @EJB, контейнер автоматически внедрит зависимость.

Отсутствие необходимости поиска JNDI означает, что вы можете проверить свой EJB как POJO для целей модульного тестирования. Вы можете просто вручную ввести фиктивные реализации зависимостей и протестировать их, не развертывая их в контейнере.

...