포스트

08. Service 클래스 만들기

interface와 class

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Service에서 interface와 class를 구현한다

Service Interface를 사용하는 이유
1) 프로젝트의 규칙성을 부여하기 위해서

2) Spring AOP를 위해서 필요
- class A : 메소드 1, 2, 3
- class B : 메소드 2, 6
- class C : 메소드 3, 10

이렇게 같은 메소드가 흩어져 있는 경우, AOP는 흩어진 관심사라고 한다
흩어진 관심사 : 
소스코드상에서 계속 반복해서 사용되는 메소드들이 여러번 정의되어 사용되는  -> 유지보수를 어렵게 만든다
이렇게 흩어진 메소드들을 모듈화하여 묶는 

3) 클래스간의 결합도를 약화 시키기 위해서 -> 유지보수성 향상
1
2
3
4
5
6
7
public interface MemberService {
  // 모든 메서드가 추상 메서드 (묵시적으로 public abstract)
  // -> 메서드 바디가 없는 미완성 메서드, 상속 받은 클래스에서 메서드를 재정의 해야 한다
  // 모든 필드는 상수 (묵시적으로 public static final)
  
  public abstract Member login(Member inputMember);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@Service // 비즈니스 로직(데이터 가공, DB 연결)을 처리하는 클래스임을 명시 + bean 등록
        // 여기서 bean으로 등록을 했기 때문에 controller에서 @Autowired로 받을 수 있었다
public class MemberServiceImpl implements MemberService{
// 상속을 받아도 POJO를 위배하지 않는다
// 왜?? POJO의 위배는 외부 라이브러리를 상속 받을 때 발생하고,
// 내가 만든 것을 상속받는 것은 위배되지 않는다

  @Autowired
  private MemberDAO dao;
  
  /* Connection을 Service에서 얻어왔던 이유
  - Service의 메서드 하나는 요청을 처리하는 업무 단위
  -> 해당 업무가 끝난 후 트랜잭션을 한번에 처리하기 위해서 
    어쩔 수 없이 Connection을 Service에서 얻어올 수 밖에 없었다 */
  
  @Override // 추상메서드 정의
  public Member login(Member inputMember){
  
    Member loginMember = dao.login(inputMember);
  
    return loginMember;
  
    // Connection을 얻어오거나 / 반환하거나
    // 트랜잭션을 처리하는 구문을 작성하지 않아도
    // spring에서 제어를 하기 때문에 Service 구문이 간단해진다
  }
}