EJB3 비즈니스 로직 패턴 및 실습

Question

저는 EJB3(앱 및 웹 서비스 레이어용 Hibernate + Glassfish, 웹 UI용 Lift on Glassfish)를 사용하여 Java로 다계층 금융 처리 애플리케이션을 개발하는 중인데, 어디로 가야 할지 고민하고 있습니다. 내 비즈니스 논리를 넣어.

이 프로젝트가 시작되었을 때 우리의 첫 번째 개념은 대부분의 비즈니스 로직을 Stateless Session Bean에 넣는 것이었습니다.그러나 시간이 지남에 따라 우리는 EJB 프레임워크에서 제공하는 종속성 주입이 너무 제한적이라는 것을 알게 되었고, 따라서 많은 비즈니스 로직이 무상태 세션 빈의 @PostConstruct 메소드에서 Guice에 의해 조립된 POJO로 끝났습니다. .이러한 진행으로 인해 세션 Bean과 POJO 간의 비즈니스 로직이 조각화되었으며 이를 수정하기 위한 접근 방식을 찾으려고 노력하고 있습니다.

처음에 우리는 웹 계층이 세션 Bean의 원격 인터페이스를 사용하여 @WebService 주석이 달린 상태 비저장 세션 Bean에서 제공하는 UI와 웹 서비스 계층 모두에서 액세스할 수 있는 일부 기능을 수행하도록 하려고 했습니다.이는 지속성 및 성능 관점에서 볼 때 악몽이었습니다. 엔터티 그래프가 상당히 커질 수 있고 분리된 엔터티 그래프를 지속성 컨텍스트에 다시 연결하는 것은 오류가 발생하기 쉬운 것으로 판명되었기 때문에 우리의 솔루션은 객체 전달을 시작하는 것이었습니다. 식별자를 사용하고 필요할 때마다 데이터베이스에서 엔터티를 검색합니다.

내 기본적인 질문은 다음과 같습니다.비즈니스 로직이 Session Bean에 들어가야 하는지 아니면 POJO에 들어가야 하는지 결정하기 위해 어떤 원칙과 지침을 제안할 수 있습니까?복잡한 객체 그래프가 있는 경우 엔터티 빈을 전달하는 것이 언제 의미가 있습니까?

Answer 1

JPA, EJB3, Wicket을 사용하여 웹앱을 구축하는 동안 이 문제로 어려움을 겪었습니다.반복적인 쿼리로 데이터베이스를 강타하는 것이 메모리에 많은 대규모 엔터티를 보유하는 것보다 확장성이 더 높기 때문에 엔터티 자체는 전달하지 않고 해당 ID만 전달하기로 결정했습니다.

Wicket과 모델 개념은 이 결정과 많은 관련이 있습니다.loadableDetachableModel은 ID를 계속 유지하면서 사용하지 않을 때 엔터티를 정리합니다.내 경우에는 Stateless Session Bean을 호출하여 엔터티가 다시 필요할 때 엔터티를 가져오는 방법을 아는 load() 메서드가 구현되었습니다.persist() 메소드는 상태 비저장 Bean을 호출하여 변경 사항을 유지합니다.이 모델 클래스는 제가 실제로 전달하는 것입니다.Wicket은 표시 및 입력 유효성 검사와 관련된 논리만 처리하며 ejb를 모델 클래스에 주입하기만 하면 됩니다.아마도 앱에서 비슷한 것을 만들 수 있을 것입니다(리프트가 어떤 기능을 제공하는지 전혀 모르겠습니다...).

이것은 나에게 잘 맞았지만 특별히 복잡한 비즈니스 논리가 없으며 지속되어야 하는 모든 변경 사항을 작은 논리 단위와 단일 페이지로 격리할 수 있습니다.

Answer 2

많은 "시스템"서비스 (주입 등)가 필요할 때마다 상태가없는 콩을 사용하십시오. 그렇지 않으면 -pojos. Pojos는 훨씬 더 유연합니다.

그러나 간단한 (액세서?) 방법 (예 : 웹 서비스 및 콩)은 간단한 작업을 수행하고 결과를 반환 할 수 있습니다.