스프링 또는 EJB3 또는 이들 모두를 함께 사용하는 것이 언제 필요하거나 편리합니까?
저는 JSF2+Spring+EJB3와 그 어떤 조합을 사용하는 것에 대해 조금 혼란스럽습니다.Spring의 주요 특징 중 하나가 의존성 주사라는 것을 알고 있지만 JSF 관리 원두를 사용하면 사용할 수 있습니다.@ManagedBean그리고.@ManagedProperty주석을 달면 저는 의존성 주입 기능을 갖게 됩니다.EJB3에서는 JSF와 함께 언제 사용해야 하는지, 사용해야 할 이유가 있는지 더욱 혼란스럽습니다.
그래서 어떤 상황에서 Spring+J를 사용하는 것이 좋을까요?SF2? EJB3+JSF2?
지금까지 저는 JSF2만을 사용하여 작은 웹 애플리케이션을 몇 개만 만들었고 스프링이나 EJB3를 사용할 필요는 없었습니다.하지만 저는 많은 곳에서 사람들이 이 모든 것들을 함께 가지고 일하는 것을 보고 있습니다.
우선, Spring과 EJB(+JTA)는 경쟁 기술이므로 일반적으로 동일한 응용 분야에서 함께 사용되지 않습니다.둘 중 하나를 선택합니다.스프링 또는 EJB(+JTA).어느 쪽을 선택할지는 말씀드리지 않고, 결정을 쉽게 내릴 수 있도록 역사와 사실만 조금 알려드리겠습니다.
이들이 해결하려는 주요 문제는 자동 트랜잭션 관리 기능을 갖춘 비즈니스 서비스 계층 API를 제공하는 것입니다.단일 비즈니스 작업(예: 주문하기)을 수행하기 위해 여러 개의 SQL 쿼리를 실행해야 하는데 그 중 하나가 실패했다고 생각해 보십시오. 그러면 당연히 모든 것이 롤백되어 DB가 이전과 동일한 상태로 완전히 아무 일도 일어나지 않은 것처럼 유지되는 것이 좋습니다.트랜잭션을 사용하지 않으면 처음 쿼리가 실제로 성공했기 때문에 DB가 잘못된 상태로 남게 됩니다.
기본 JDBC를 잘 알고 있다면 연결에서 자동 커밋을 해제한 다음 해당 쿼리를 순차적으로 실행하면 이를 달성할 수 있음을 알아야 합니다.commit()마찬가지로try누구의catch (SQLException) a rollback()수행됩니다.그러나 이는 매번 구현하기에는 매우 지루합니다.
Spring and EJB(+JTA)에서는 단일(상태 없는) 비즈니스 서비스 방식 호출이 기본적으로 단일 전체 트랜잭션으로 투명하게 계산됩니다.이렇게 하면 트랜잭션 관리에 대해 전혀 걱정할 필요가 없습니다.수동으로 생성할 필요가 없습니다.EntityManagerFactory, 명시적으로 부르지도 않는em.getTransaction().begin()비즈니스 서비스 로직을 JSF 백업 빈 클래스에 긴밀하게 연결하거나 사용할 때와 같은 작업을 수행할 수 있습니다.RESOURCE_LOCAL대신에JTAJPA에서예를 들어, JPA를 사용하여 다음과 같은 EJB 클래스를 가질 수 있습니다.
@Stateless
public class OrderService {
@PersistenceContext
private EntityManager em;
@EJB
private ProductService productService;
public void placeOrder(Order newOrder) {
for (Product orderedproduct : newOrder.getProducts()) {
productService.updateQuantity(orderedproduct);
}
em.persist(newOrder);
}
}
만약 당신이.@EJB private OrderService orderService;당신의 JSF backing bean에서 그리고 호출.orderService.placeOrder(newOrder);작업 방식에서는 단일 전체 트랜잭션이 수행됩니다.예를 들어 다음 중 하나를 선택할 경우updateQuantity()콜 또는 더persist()예외로 호출에 실패했습니다. 그러면 지금까지 실행된 것을 롤백합니다.updateQuantity()호출하고 DB를 깨끗하고 선명한 상태로 유지합니다.물론 JSF 백빈에서 그 예외를 포착하고 얼굴 메시지를 표시할 수도 있습니다.
주목할 점은 "봄"은 EJB뿐만 아니라 CDI 및 JPA와 경쟁하는 상당히 큰 프레임워크라는 것입니다.이전에, 어두운 J2EE 시대에, EJB 2.x는 구현하기에 매우 끔찍했습니다(위의 EJB 3.x).OrderService예를 들어 EJB 2.x의 경우 최소 5배 이상의 코드와 일부 XML 코드가 필요합니다.스프링은 자바 코드를 덜 필요로 하는 훨씬 더 나은 대안을 제공했습니다.J2EE/EJB2는 Spring에서 교훈을 얻었으며, Spring보다 훨씬 더 매끄러운 새로운 EJB3 API를 제공하고 XML이 전혀 필요 없는 Java EE 5와 함께 제공되었습니다.
스프링은 또한 IoC/DI(제어의 반전; 의존성 주입)를 박스 밖으로 제공합니다.이것은 XML로 구성된 J2EE 시대의 것으로, 상당히 과도할 수 있습니다.요즘 Spring도 주석을 사용하지만 여전히 약간의 XML이 필요합니다.6 Spring에서 후기능을 . DI Java EE 에서 Spring은 CDI, DI, XML로 구성됩니다. 스프링 DI로@Component/@Autowired CDI고 CDI.@Named/@Inject가 JSF는은을할수다과은다수할jehuesen은j을fs는은과fe@ManagedBean/@ManagedProperty그것을 더 합니다: 를 들어, 또는 콩 에 쓸 수 , 지정 소비자를 수 , 더에 더 할 수 DI CDI 는그 주변에 더 많은 이점을 제공합니다: 예를 들어, 당신은 인터셉터를 사전 처리 또는 사후 처리 관리 콩 생성/파괴에 쓸 수 있고, 사용자 지정 범위, 생산자 및 소비자를 만들 수 있고, 더 넓은 범위의 인스턴스에 더 좁은 범위의 인스턴스를 주입할 수 있습니다.
스프링은 또한 JSF와 본질적으로 경쟁하는 MVC를 제공합니다.JSF와 Spring MVC를 혼합하는 것은 말이 안 됩니다.또한 기본적으로 JPA보다 추상화 계층인 데이터를 제공하여 DAO 보일러 플레이트를 더욱 최소화할 수 있습니다(하지만 비즈니스 서비스 계층 전체를 나타내는 것은 아님).
참고 항목:
봄은 많은 것이기 때문에 여기에 정말 쉬운 답은 없습니다.
Spring은 Java EE와 매우 높은 수준에서 경쟁하므로 둘 중 하나를 전체 스택 프레임워크로 사용할 수 있습니다.
좀 더 세분화된 수준에서, Spring IoC 컨테이너와 Spring Beans는 Java EE에서 CDI & EJB의 조합과 경쟁합니다.
웹 계층의 경우, Spring MVC는 JSF와 경쟁합니다.일부 Spring xyzTemplate는 JPA 인터페이스와 경쟁합니다(둘 다 Hibernate와 같은 인터페이스를 구현할 수 있습니다)
CDI & EJB 원두를 Spring MVC와 함께 사용하거나 Spring Beans를 JSF와 함께 사용하는 등 혼합 및 매칭이 가능합니다.
일반적으로 직접적으로 경쟁하는 두 기술을 함께 사용하지 않습니다.같은 앱에서 봄콩 + CDI + EJB, 아니면 봄 MVC + JSF가 우스꽝스럽습니다.
언급URL : https://stackoverflow.com/questions/18369356/when-is-it-necessary-or-convenient-to-use-spring-or-ejb3-or-all-of-them-together
'bestsource' 카테고리의 다른 글
| E: 'mysql-client' 패키지에 도커 구성을 사용하는 php-fpm 이미지 빌드에 설치 후보가 없습니다. (0) | 2023.09.06 |
|---|---|
| 스프링 세션 범위 콩(컨트롤러) 및 서비스에 대한 언급, 직렬화 측면 (0) | 2023.09.06 |
| html 요소를 ajax 응답으로 대체하는 방법은? (0) | 2023.09.06 |
| jQuery & CSS - 디스플레이 제거/추가: 없음 (0) | 2023.09.06 |
| 함수의 정의에 함수 프로토타입 형태의 def를 사용할 수 있습니까? (0) | 2023.09.06 |