avaStatic 팩토리 패턴 (EJB3/JBoss 포함)

Question

저는 Java EE의 제한된 사용으로 내 경력 대부분을 위해 특수 목적의 독립형 Java 응용 프로그램을 작성하고 작업 한 JBoss와 같은 완전 분사 응용 프로그램 서버 및 EJB에 상당히 익숙합니다. EJB3와 JBoss에 일반적으로 사용되는 디자인 패턴 인 정적 팩토리 패턴을 적용하는 가장 좋은 방법에 대해 궁금합니다. CredentialsProcessor의 구현 클래스에

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

그러나, 나는 주입이 필요합니다 : 사실이 (제 2 판) 내가 현재 다음과 같은 공장에서 함께 일하고 있어요

조슈아 블로흐의 효과적인 자바 책 항목 # 1 PersistenceContext과 같은 리소스가 있으므로 CredentialsProcessor 인터페이스를 @Local 인터페이스로 만들고 각 impl을 @Stateless으로 표시했습니다. 이제 JNDI에서 살펴보고 주입 된 리소스를 사용할 수 있습니다.

하지만 이제 공장을 더 이상 사용하지 않아 연결이 끊어졌습니다. 내 첫 번째 생각은 getProcessor(CredentialsType) 메서드를 변경하여 JNDI 조회를 수행하고 필요한 SLSB 인스턴스를 반환하지만 적절한 정규화 된 JNDI 이름을 구성하고 전달해야합니다. 내가 그 길을 가기 전에, 나는 받아 들여진 관행들에 대해 더 많은 연구를하고 싶었다.

이 디자인 패턴이 EJB3에서 처리되는 방법/자바 EE는? -

Answer 1

팩토리 및 "실제"Java POJO 코드로 재생을 시작하면 기본적으로 JNDI가 필요합니다.

종속성 삽입은 EJB 서버의 관리되는 구성 요소에서만 작동하며 기본적으로 Servlets 및 EJB입니다.

EJB를 참조하려는 일반 Java 코드를 말하면 JNDI를 통해 리소스를 직접 조회해야합니다.

그런 경우 가장 좋은 방법은 각 구현에서 직접 JNDI를 호출하는 대신 JNDI 조회를 수행하는 정적 함수로 채워진 래퍼 조회 클래스를 작성하는 것입니다. 그리고 그것을 구현에 사용하십시오.

이것은 일반적인 일반적인 규칙입니다.

이제 구체적인 경우를 고려해보십시오.

당신은이 :

다르지 없습니다

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

: 당신의 getProcessor() 코드에서

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

다음 :

이

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

이

참조, 기본적으로 코드가 동일 입니다 , 공장 인터페이스는 클라이언트와 동일합니다.

JNDI 조회 키를 "하드 코딩"해야하지만, 어쨌든 클래스 이름을 "하드 코딩"해야하므로 어떻게 다른가요?

모든 컨테이너에서 잠재적 인 이식성 문제가 있습니다. 모든 사람이 bean 이름에 대해 다른 JNDI 식별자를 사용하려는 것처럼 보입니다. 대부분의 배포에서 조정할 수 있지만 그렇지 않다면,이 키들을 설정 파일이나 다른 것으로 가져올 수 있습니다.

Java EE 6에는 이동 가능한 이름이 있습니다. 컨테이너를 포팅하지 않는다면 전혀 걱정할 필요가 없습니다.

그래서 기본적으로 전혀 연결이 끊어지지 않습니다.

Answer 2

EJB3와 함께, 당신은 일반적으로 JNDI 조회를 수행 할 필요가 없습니다. EJB3는 dependency injection의 EJB와 몇 가지 다른 유형의 자원을 지원합니다. bean 속성에 @EJB이라는 주석이있는 경우, 종속성은 컨테이너에 의해 자동으로 주입됩니다.

JNDI 조회를 할 필요가 없다는 것은 단위 테스트 목적으로 EJB를 POJO처럼 테스트 할 수 있음을 의미합니다. 의존성에 대한 mock 구현을 수동으로 삽입하고 컨테이너에 배치하지 않고 테스트 할 수 있습니다.