Bean을 인스턴스화하기 위해 Spring을 사용하지 않을 때?

14

Spring의 올바른 사용법이 무엇인지 이해하려고합니다. 문법적으로는 아니지만 목적 상으로 말입니다. Spring을 사용하고 있다면 Spring 코드가 모든 bean 인스턴스화 코드를 대체해야합니까? Bean을 인스턴스화하기 위해 Spring을 사용하거나 사용하지 않을 때?

다음 코드 샘플이 내 딜레마를 이해하는 데 도움이 될 수 있습니다.

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = new ClassA();
    ca.setName(name);
    caList.add(ca);
}

Spring을 구성하면 다음과 같이됩니다.

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
    ca.setName(name);
    caList.add(ca);
}

개인적으로 여기 Spring을 사용하는 것은 불필요한 오버 헤드라고 생각합니다.

읽고 이해하기 쉬운 코드입니다.
다중 / 가변 구현이있을 것이라고 기대하지 않기 때문에 나중에 의존성 주입을위한 좋은 장소는 아닙니다 ClassA. 나중에 스프링 구성을 사용하여 자유롭게 교체하고 싶습니다.

내가 올바른 생각입니까? 그렇지 않다면, 내가 어디로 잘못 가고 있습니까?

java spring

— 리 샤브
소스

14

맞습니다. Spring은 나열된 사용 사례에 적합하지 않습니다. Spring은 외부 의존성 (JDBC 연결을 DAO에 연결하는 것과 같은) 또는 구성 (사용할 데이터베이스 유형 지정과 같은)을 관리하는 데 더 적합합니다. 예를 들어, Bean 유형이 변경되기 쉬운 경우 인터페이스를 사용하여 Bean을 지정하고 Factory를 사용하여 Bean을 인스턴스화하십시오. Spring을 사용하여 사용할 팩토리를 지정하고 Bean을 인스턴스화하는 데 필요한 클래스에 팩토리를 삽입하십시오. 그런 다음 여러 가지 다른 유형의 Bean (모두 Bean 인터페이스를 지원하는)을 작성하는 여러 가지 팩토리를 보유하고 설치 (또는 업데이트)시 적절한 하나를 구성 할 수 있습니다.

— TMN
소스

9

레이어 사이에 Spring (또는 다른 DI 시스템)을 사용하고 레이어 내에서 직접 인스턴스화합니다.
따라서 해당 클래스의 범위를 떠나서 (기능적으로) 외부 시스템 (해당 시스템 또는 일부 통신 계층에 의해 정의 될 수있는)으로 Bean을 작성하는 클래스는 DI를 통해 작성됩니다. 응용 프로그램 계층 내에서 내부적으로 사용하기 위해 작성된 다른 Bean은 코드 명확성 및 (중요한 시스템과 마찬가지로) 성능상의 이유로 직접 작성됩니다.

— wen
소스

이것은 또한 나에게 유효한 답변입니다! 슬프게도 하나의 답변 만 선택할 수 있습니다.

— Rishabh

1

그것은 경우 콩이 , 당신은 당신이 공장 빈을 제공 할 수 있습니다 제외하고 봄이 (그것을 구축하도록해야 - 당신이에 설명서를 참조해야한다 - 내가 특정 서브 클래스에 의존하는 시스템 특성에를 반환하는 데 필요한 곳 사용했습니다 @Configuration및 @Bean주석 당신이 그렇게하는 경우). Bean이 아니라 Plain Old Java Object 인 경우 Spring을 사용하여 전혀 만들 필요가 없습니다. POJO는 유용하지만 Spring이 추가하는 것들이기 때문에 의존성 주입, AOP 래퍼 등을 얻지 못합니다.

근본적인 결정은 그것이 진짜 콩인지 아닌지 또는 어떤 콩 규칙 (예를 들어, 메소드 명명)을 따르는 일반적인 객체 일지 여부입니다. 나는 당신이 준 작은 예에서 실제로 어떤 경우인지 추측 할 수 없습니다.

— 도널 펠로우
소스

안녕하세요 Donal, ClassA가 비즈니스 로직이 풍부한 도메인 클래스 인 경우 답변이 동일합니까?

— Sameer Patil

0

나는 잘못된 전문가 일 수 있습니다.

스프링 컨텍스트에서 Bean의 전체 개념은 Spring Container가 객체를 관리한다는 것입니다. 그것은 스코프 수명주기 죽음 등의 탄생입니다. 마치 객체의 관리인과 같습니다. 필요한 어플리 케이트가 주입됩니다.

따라서 모듈을 디자인하는 동안 결정을 내릴 때 항상 Spring 프레임 워크를 관리 할 것인지 또는 수명주기가 메소드에 포함 된 간단한 객체인지 생각하십시오.

이전에 제안한 dao 객체 jms 대기열 객체 등은 무겁고 스프링 프레임 워크 전문가가 처리해야합니다.

— 라훌 조시
소스