디지털 컨버전스/Spring

[Spring Framework] Service Layer

gimyeondong 2020. 6. 4. 11:52

서비스 레이어의 등장 배경

 

기존의 방식도 나쁘진 않지만 좀 더 미래 지향적인 코드를 적용하기

장기적으로 유리

 

 

현재 우리가 짜는 컨트롤러 코드는 플랫폼 종속성을 갖는다.

 

톰캣, 스프링 프레임 워크 : 현재 의존하고 있는 플랫폼

 

 

DAO는 데이터베이스 플랫폼에 종속

 

 

모호성이 생기는 시점 : 이 코드가 컨트롤러인가? DAO인가?

 

게시판의 네비게이터 로직

이전에는 DAO에 넣었지만 원래 DAO는 데이터베이스 관련된 기능만 들어가야 최적화

컨트롤러는 웹과 관련된 기능만 담당해야 최적화.

 

 

서비스레이어

플랫폼 종속성을 가지지 않는 분리 가능한 매커니즘을 저장하는 계층

비지니스 로직 저장

 

리퀘스트, 리스폰스, session 등 웹 관련은 컨트롤러에만 존재

connection은 DAO에만 존재

컨트롤러와 DAO가 받아온 숫자만 서비스레이어로 전달

서비스레이어는 덧셈뺄셈 로직만 구동

 

 

장점 : 서비스레이어는 웹이 아닌 네이티브로 가져와도 재활용 가능

똑같은 자바 프로젝트라면 복붙했을때 다 동작

 

 

 getSha512 를 매서드로 만들어서 서비스계층이 갖도록

서비스 패키지 추가

컨트롤러가 서비스레이어를 사용하고 서비스레이어가 DAO를 사용

 

컴포넌트의 자손 중

@Service

컨트롤러에서 서비스로 boardWrite() 콜

form 으로 받는값 뿐아니라 session에서 꺼내는 경우 (글쓴이 아이디)

 

아이피가 필요한 경우

리퀘스트는 오토와이어드도 해서는 안되고 서비스에서 쓰이지 않음 -> 컨트롤러에서만 사용

 

 

 

의존성 없는 코드를 구분하기 어려운 상황도 있음.

서비스레이어를 거쳐서 사용하기 불편하지만 그래도 미래를 대비해서 사용할 것