Spring Beans 선언의 이유 (일부)

Spring bean과 JavaEE의 차이점에 대해 작은 질문이 있습니다. 구성에서 Spring의 일부 Bean을 정의해야하는 이유는 무엇입니까? JavaEE가 아닌가요?Spring Beans 선언의 이유 (일부)

감사합니다.

2016-08-01 smsnheck

이것은 작은 질문이 아닙니다.

JavaEE는 표준 방식으로 서비스를 제공하는 컨테이너를 가졌다 고 가정합니다. 특정 버전의 스펙에 설명 된 일부 또는 모든 API를 구현하는 응용 프로그램 서버에서 응용 프로그램을 실행합니다. Servlet, JSP, 트랜잭션 관리, JPA, CDI, 인증 및 권한 부여 ...

Spring은 대부분 EJB 2의 루틴에서 태어난 다른 짐승입니다. 초기 200x. 먼저 전체 컨테이너 (데이터 계층을 다르게 수행 할 수 있음을 의미)를 필요로하지 않으며 종속성 주입 (DI)의 이점을 얻을 수 있음을 보여줍니다. 처음에는 Spring이 XML 파일을 통해 수행되는 DI에 관한 것이 었습니다. 이것들은 당신이 언급하고있는 설정 파일입니다. Spring Integration, Spring Web Services, Spring Data, Spring Boot, JavaEE와의 경쟁 기능 등 다양한 하위 프로젝트가있었습니다. EJB 2는 Hibernate에서 영감을 얻은 EJB 3에 찬성하여 삭제되었습니다. 주석은 구성 파일 등으로 선호되었습니다. 이것은 매우 유기적 인 프로세스로 좋은 아이디어가 개선되도록 노력했습니다. 아직 XML 파일에서 구성 클래스에 흩어져있는 주석과 구성 전용 클래스에서 구성이 유지되었습니다. 이는 Spring의 단점으로 볼 수 있지만이 복잡성으로 인해 엄청난 양의 데이터를 통합 할 수 있습니다 libs와 middlewares를 사용하고 응용 프로그램을 사용자가 보게되는 모양으로 만듭니다.

JavaEE와 Spring은 최근 경쟁이 치열 해지고 있습니다. JavaEE는 최근에 Spring의 훌륭한 아이디어 중 일부를 취하고 있습니다 (예 : CDI). 그러나 각각의 컨테이너가 기본 컨테이너에 제공하는 역할은 완전히 다릅니다.

출처

2016-08-01 19:27:20

자세한 답변 해 주셔서 감사합니다. 그러나 당신의 대답을 봄에 왜 콩을 정의하는 것이 Spring에서 필요한지 불분명합니다. 표준 JavaEE 애플리케이션에서 내가 원하는 모든 클래스를 주입 할 수있다. Spring에서는 Bean 미리 머리를 정의 할 필요가 있습니다. 아니면 "용기"가 유일한 이유입니까? 나는 Spring 애플리케이션 컨텍스트가 일종의 컨테이너라고 생각했다. – smsnheck

내가 할 수 있는지 명확히하려고 노력할 것이다. 그러나 내가 말했듯이 그것은 작은 질문이 아니다. JavaEE는 모두 컨테이너에 관한 것입니다. 서블릿과 EJB 컨테이너가 있었는데 요즘에는 프로파일에 대해 이야기 할 것이고, 웹 프로파일은 서블릿 컨테이너의 진화라고 할 수 있습니다. 그러나이 컨테이너에는 소위 엔터프라이즈 애플 리케이션에 대한 작업을 수행하는 방법에 대한 의견이 있습니다. Spring의 컨테이너는 DI 컨테이너입니다. XML, 주석 및 구성 요소 스캔, Java 구성과 같은 선언 형식을 기반으로 한 와이어 오브젝트 이외의 기능은 제공하지 않습니다. 어떤 기술로 무엇을 연결할지 결정하는 것은 당신의 것이 었습니다. –

감사합니다. 이제 나는이 원리들을 이해한다. – smsnheck

Spring Beans 선언의 이유 (일부)

답변

관련 문제