[SPRING] 왜 항상 서비스 및 DAO 계층에 단일 구현 인터페이스가 있습니까?

왜 항상 서비스 및 DAO 계층에 단일 구현 인터페이스가 있습니까?

필자는 실제 서비스 및 DAO 클래스가있는 것처럼 많은 인터페이스를 갖는 몇 가지 봄 - 최대 절전 웹 응용 프로그램 프로젝트를 보거나 보았습니다.

필자는 항상이 두 가지가 이러한 단일 구현 인터페이스를 갖는 주된 이유라고 생각했습니다.

그러나, 늦게, 나는 깨달았다 :

Spring은 구체적인 구현 클래스를 종속물로 연결한다.

public class Person { 

@Autowired 
private AddressImpl address;

@Autowired 
private AccountDetailImpl accountDetail;

public Person(AddressImpl address, AccountDetailImpl accountDetail) { 
// constructor

EasyMock과 같은 모의 프레임 워크는 구체적인 수업을 조롱 할 수 있습니다.

AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); 
// unit test follows

또한,이 논의에 따르면, 요약하면 단일 응용 프로그램 내에서 인터페이스는 주로 관습이나 습관에서 과용됩니다. 일반적으로 전 세계 여러 응용 프로그램에서 사용되는 slf4j와 같은 다른 응용 프로그램과 상호 작용할 때 가장 적합합니다. 단일 응용 프로그램 내에서 클래스는 인터페이스와 거의 동일한 추상화입니다.

그래서, 내 질문에 우리는 여전히 인터페이스가 필요하고 * ServiceImpl 및 * DaoImpl 클래스와 같은 단일 구현을 가지고 불필요하게 코드 기반 크기를 늘리는 것입니다. 내가 모르는 구체적인 수업을 조롱하는 데 문제가 있습니까?

이 점을 팀 동료와 논의 할 때마다 인터프리터를 기반으로하는 서비스 및 DAO 클래스를 구현하는 것이 모두가 따르는 디자인이라는 것입니다. 스프링 베스트 프랙티스, OOP, DDD 등을 언급합니다.하지만 여전히 그렇지 않습니다. 격리 된 응용 프로그램 내에서 너무 많은 인터페이스가있는 이유는 실용적인 이유입니다.

해결법

1. ==============================

   1.인터페이스에는 더 많은 이점이 있습니다. 클래스가 인터페이스를 구현하면 JDK 동적 프록시가 AOP에 기본적으로 사용됩니다. 구현을 직접 사용하면 proxy-target-class = true로 설정하여 CGLIB 프록시를 사용해야합니다. JDK 프록시와 달리 바이트 코드 조작이 필요합니다.

   인터페이스에는 더 많은 이점이 있습니다. 클래스가 인터페이스를 구현하면 JDK 동적 프록시가 AOP에 기본적으로 사용됩니다. 구현을 직접 사용하면 proxy-target-class = true로 설정하여 CGLIB 프록시를 사용해야합니다. JDK 프록시와 달리 바이트 코드 조작이 필요합니다.

   이것에 대한 자세한 내용은 여기를 참조하십시오.

   어떤 이유로 더 많은 정보를 얻기 위해 인터페이스 (Java EE 또는 Spring과 JPA)를 사용해야하는지에 대한 다른 토론을 읽으십시오.

2. ==============================

   2.그것은 매우 논란의 대상입니다. 간단히 말해서, 개발자에게는 최소한 아무 것도 없습니다.

   그것은 매우 논란의 대상입니다. 간단히 말해서, 개발자에게는 최소한 아무 것도 없습니다.

   EJB2 세계에서 가정과 원격 인터페이스는 필수 였고, 이유가 바로 그 것이었다. @AravindA는 프록시라고 언급했다. 보안, 리모팅, 풀링 등은 모두 프록시로 래핑 될 수 있으며 표준 라이브러리 내에서 엄격하게 요청 된 서비스를 제공합니다 (DynamicProxy 에서처럼).

   이제 우리는 javaassist와 cglib을 가지고 있기 때문에 Spring (Hibernate, EJB3)은 프레임 워크 개발자가 좋아하는 클래스를 완벽하게 구현할 수 있습니다. 문제는 그들이하는 일은 매우 성가신 일입니다. 그들은 매개 변수없는 생성자를 추가하도록 요청합니다 .- 잠깐, 여기에 매개 변수가 있습니까? - 단, 생성자를 추가하지 마십시오.

   그래서 인터페이스는 당신의 정신을 유지하기 위해 여기에 있습니다. 그래도 이상하지 않은데, 적절한 생성자를 가진 클래스의 인수가없는 생성자는 내게 의미있는 것이 아닙니다. 맞습니까? Spring이 클래스의 인터페이스와 동등한 기능을 생성한다는 사실을 밝혀야한다. 즉, (또는 무시 된) 상태가없는 인스턴스와 모든 메소드가 무시된다. 따라서 "진짜"인스턴스와 "가짜 인터페이스"가 있으며, 가짜 인터페이스는 모든 보안 / 트랜잭션 / 원격 처리 기능을 제공합니다. 멋지지만 이해하기 어렵고, 별개로 생각하지 않으면 버그처럼 보입니다.

   게다가 클래스에 인터페이스를 구현하는 경우 (적어도 일부 버전의) Spring은 갑자기이 인터페이스 만 프록시 할 것이라고 결정하고 응용 프로그램이 명백한 이유없이 작동하지 않습니다.

   따라서 지금까지의 이유는 안전과 온건함입니다. 좋은 연습이 필요한 이유가 있습니다. 그러나 게시물에서 나는 이미 그 모든 것을 읽었습니다. 오늘 볼 수있는 가장 중요한 이유는 WTH / 분 측정 항목입니다. 특히 프로젝트 신규 사용자에 대해 이야기하는 경우 더욱 그렇습니다.

from https://stackoverflow.com/questions/8922135/why-always-have-single-implementation-interfaces-in-service-and-dao-layers by cc-by-sa and MIT license