지난번에 service를 나누는 이유에 대한 글을 포스팅하였다.
이번에는 service의 구현 클래스에 대해 조금더 이야기를 나눠보자.
인터페이스로 service를 만들어 service를 구현한 클래스를 통해 @service를 사용하였다.
이 service 클래스는 ,
요청클래스(Contorller)와 DAO클래스(Model)사이의 연결 사이에서 완충 지대 역할을 지닌다.
즉 ,Contorller와 Model 사이에 변경사항이 생기더라도 서로 영향을 받지 않도록 해주는 역할
결합도는 낮추고 응집도는 높이도록 한다.
service interface
public interface MemberService {
// ** selectList
List<MemberDTO> selectList();
// ** selectOne
MemberDTO selectOne(String id);
// ** insert
int insert(MemberDTO dto);
// ** update
int update(MemberDTO dto);
// ** delete
int delete(MemberDTO dto);
}
혹여나 이를 구현한 클래스가 여러개라도 , @Service 애노테이션을 통해 일치하는 타입을 찾기 때문에 ,
실사용될 클래스에 @Service 만 사용한다면 , 해당하는 클래스를 주입한다.
추후에 클래스의 내용을 바꾸거나 하고싶다면 , 클래스들 중 애노테이션만 바꿔준다면 , 적용되기 때문에
결합도를 낮췄다고 볼 수 있고 , 확장성이 높아지게 된다.
인터페이스를 통해 여러 구현체를 자유롭게 대체할수 있는 다형성을 이용하는 부분이다.
같은 타입의 클래스를 주입하는 경우 예외가 발생할 수 있는데 , 그로 인한 문제를 해결하는 방법은 다음과 같다.
- @Primary 애노테이션의사용.
@Service
@Primary
public class FirstServiceImpl implements MyService {
// 구현 내용
}
=> 기본으로 설정.
2. @Qualifier("class_name") 애노테이션의 사용
@Service
public class FirstServiceImpl implements MyService {
// 구현 내용
}
@Service
public class SecondServiceImpl implements MyService {
// 구현 내용
}
@Autowired
@Qualifier("firstServiceImpl")
private MyService myService;
=> 원하는 빈의 이름으로 설정.
@Service와 빈 생성의 특징
스프링에서 기본적으로 @Service 애노테이션을 사용한 클래스는 싱글톤으로 관리된다.
즉 , 한번 생성된 서비스 빈은 스프링 컨텍스트에서 애플리케이션 종료시 까지 재사용된다.
이를 통해 성능 최적화 및 자원 효율성이 높아지고 ,
대규모 어플리케이션에서 동일한 서비스객체를 여러곳에서 효율적으로 활용할 수 있다.
'Developer > Spring eGov4.0 (Java11, Tomcat9)' 카테고리의 다른 글
Spring , 영속 계층의 프레임 워크, myBatis와 JPA차이 , OMR이란 (2) | 2024.10.28 |
---|---|
Spring , passwordEncoder (0) | 2024.10.28 |
Spring , log message (0) | 2024.10.27 |
Spring , 기본 mvc 패턴 제작형식 , 주요 애노테이션 (1) | 2024.09.27 |
spring , service를 나누는 이유 (0) | 2024.09.27 |