우리는 여러 데이터 소스에 접근하는 상당히 복잡한 프로젝트를 수행하고 있습니다. 현재 우리는 최대 64 개의 웹 서비스 트랜잭션을 처리하고 있으며 더 많은 것을 추가 할 예정입니다. 우리는 정의 된 서비스 계층과 DAO를 가지고있다. 서비스 계층 클래스는 일반적으로 데이터를 조회하는 작업을 수행하는 하나 이상의 DAO 클래스를 가지고 있습니다. DAO 클래스는 스프링 xml 배선을 사용하여 서비스 계층 클래스에 연결됩니다.빈을 연결하는 이점
DAO 클래스에는 모두 인터페이스와 Impl가 있습니다. 여기서 핵심은 오직 하나의 Impl 만 있다는 것입니다. 비록 임프란트가 변경 될 수 있지만 DAO 계층은 안정적인 레거시 시스템에서 비롯되기 때문에 가능성은 희박합니다.
그렇다면 임 플란 트가 하나만있을 경우 스프링 배선을 사용하면 어떤 이점이 있습니까? 왜 서비스 계층 클래스에서 클래스를 인스턴스화하지 않는가?
하나의 이유는 단위 테스트이기 때문에, 클래스가 자신을 인스턴스화하는 경우 클래스를 mocks와의 종속성에서 분리 할 수 없습니다.
인터페이스를 사용하면 Spring이 JDK 동적 프록시를 사용하여 AOP 프록시 (예 : 선언적 트랜잭션 관리)를 만들 수 있다는 이점이 있습니다. 그렇지 않으면 CGLIB가 필요합니다. Spring docs에서 - 선택이있을 때마다 JDK 동적 프록시가 선호됩니다. http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/aop.html#aop-proxying -
좋은 답변이므로 +1. 우리의 경우에는 그렇게하지 않습니다. 우리는 아마 그래야합니다. –
다른 이유가 추가되었습니다. –
DAO는 구현 클래스 (데이터 소스 URL, 연결 풀 매개 변수 등) 이외의 다른 구성을 필요로 할 수 있습니다. 의존성 주입 철학에서 이러한 세부 사항은 구성을 구성하기 때문에 코드에서 제외해야합니다. 서비스 클래스는 엄격하게 비즈니스 로직을 포함해야합니다. 이것은만큼 자동으로 CustomerDAOImpl을 주입하는 봄의 원인이됩니다
@Inject
private CustomerDAO customerDAO;
:
는, 거기에 코드 메타 데이터에 찬성 XML 기반 구성 설명에 대한 반발이었다과 같이했다고 말해 두 겠는데 발견 된 유일한 CustomerDAO 구현입니다. CustomerDAOImpl 클래스에는 차례대로 필요한 모든 구성 세부 사항을 지정하는 다른 주석이있을 수 있습니다.
필요하지 않다고 생각하는 경우에도 사용하는 데에는 여러 가지 이유가 있습니다. 나는이 기사가 그들을 아주 잘 요약한다고 생각한다.
http://tutorials.jenkov.com/dependency-injection/dependency-injection-benefits.html
그래서 서비스를 테스트 할 수 있습니다. –