1

JavaEE 6 튜토리얼을 읽었으며 SessionBean과 CDI 섹션을 읽는 동안 몇 가지 의문점이있었습니다.SessionBeans와 CDI와 POJO 클래스

1) 이해를 돕기 위해 @EJB 주석은 SessionBean을 주입하여 종속성 삽입 패턴을 사용합니다. 나는이 패턴이 누가 어떤 물건을 만들지에 대한 책임감을 바꾸는 것을 목표로한다는 것을 이해한다. 따라서, 의존성을 소유하고있는 특정 클래스 대신에, 생성자에서 의존성을받습니다. 그러나 @EJB 주석은 종속성을 주입하지 않는 문제를 어떻게 완화합니까? @Inject 주석에도 동일하게 적용됩니다.

2) 날짜를 여러 형식 (yyyy-MM-dd, dd-MM-yyyy 등)으로 포맷하는 유틸리티 클래스 (정적 메서드 만 포함)가 있습니다. 이러한 메소드에 Stateless Session Bean을 사용하는 것이 더 좋습니까? 아니면 Utility 클래스를 유지해야합니까? 이를 위해 EJB를 사용하는 경우 @Inject 주석을 사용하여 Bean을 사용하거나 Bean을 사용하는 것의 차이점은 무엇입니까?

3) Dependency Injection을 사용하는 경우 Service Locator 또는 Factory 패턴을 사용하는 것이 합리적입니까? (서비스 위치 정보가 안티 패턴으로 기록 된 것을 보았지만).

답변

1
  1. 아니요. 종속성 주입은 종속성 생성을 피하는 것이 아닙니다. 또한 컨테이너에 종속성을 요청하는 것을 피하는 것입니다. 컨테이너에 의존성을 묻는 대신 컨테이너는 구성 요소에 종속성을 주입합니다. 나는 당신이 "의존성을 주입하지 않는 문제"라는 말을 이해하지 못합니다. 명확히하십시오.

  2. 세션 빈은 일반적으로 트랜잭션, 보안 및/또는 원격 측면을 컨테이너 주변의 메소드에 추가해야하는 경우에 사용됩니다. 단지 유틸리티 클래스 인 경우, 세션 빈을 만들 필요가 없습니다.

  3. 아니요, 이해가되지 않습니다. Depoendency injection의 주요 목표는 컨테이너가 Bean에 종속성을 주입하도록하기 위해 servce locator 및/또는 factory의 사용을 대체하는 것입니다. 이것은 유닛 테스트에서 빈에 가짜 의존성 (mock 객체)을 삽입 할 수 있기 때문에 코드를 쉽게 테스트 할 수있게합니다.)

    해당 클래스에서이 유틸리티 메소드를 유지 (! 대만족)

+0

내가 말한 것은 EJB 주석이 클래스를 빈에 의존하지 않게 만드는 방법이었습니다. this.bean = new Bean();을 갖는 주요 차이점은 무엇입니까? 또는 @EJB 콩 콩? 결국 두 가지 구현 모두 클래스를 Bean에 의존하게 만들 것입니다. 맞습니까? 아니면 여기에 개념을 혼합하고 있습니까? –

+0

종속성 삽입 지점은 종속성을 제거하는 것이 아닙니다. 그것의 요점은 외부로부터 그들을 주입하는 것이다.이렇게하면 단위 테스트에서 가짜 종속성을 수동으로 주입 할 수 있습니다. –

+0

그래서 더 많은 연구를 통해 Dependency Injection은 모의 콩 세트를 단순화하기위한 Unit 테스트 이외의 다른 작업에 실제로 더 효과적이라고 생각하게되었습니다. 나는 그것이 저쪽에 어떻게 도움이되는지 이해하려고 노력하고있다 –

2

@EJB 및 @Inject에 의해 ... 주입, 하지 주입의 문제를 완화. EJB는 트랜잭션 관리, 리소스 사용량 제한, 사용자의 역할에 기반한 메소드에 대한 액세스 제한 등을위한 것입니다. 유틸리티 메소드에는 그럴 필요가 없습니다.

대부분 유틸리티 클래스를 CDI를 통해 주입 가능하게 만들 수 있습니다 : 인터페이스를 정의하고 생산자 방법을 생성하십시오. 종종 이것은 잔인한 행동이지만 클래스의 정확한 확장과 사용법에 따라 다릅니다.

인젝션을 사용하면 여전히 생산자가 공장을 가질 수 있지만 클라이언트는 공장을 명시 적으로 사용하지 않습니다. 클라이언트는 종속성을 선언하고 CDI는 이것을 만족시키기 위해 "공장"(생산자)을 사용할 수 있습니다.

관련 문제