Repository와 Service

공부를 하던 도중 궁금한 점이 생겼다.

우리가 DB와 관련된 작업을 하기 위해선 Repository와 Service를 만들어야하는데, 다른 사람들이 작성한 코드를 보면 기능을 Repository에서 구현하기도 하고, Service에서 구현하기도 하는데, 왜 이렇게 구분하는지가 궁금했다.

(기존에 나는 service에서 구현)

 

김영한 님이 말하길 DB에 접근하는 코드는 Respository에 위임하고, Service 패키지에는 비즈니스 로직과 관련된 코드를 위임하는데, 이렇게 구분해두면 비즈니스 로직및 관련 부분에 오류가 발생하면 Service를 확인하고, DB 접근과 관련된 문제가 발생하면 Repository를 확인하면 된다고 한다.

 

서비스에서 DB계층을 연결하려고 하면 Repository라는 저장소를 두는데, 흔히 Model이라 하며 스프링에서는 레포지토리라고(Repository) 한다. 데이터를 입력하고, 수정하며, 삭제하는 등의 데이터 관련 코드는 Repository 계층에서 수행해서 Controller에 부담을 줄일 수 있으며, SQL과 관련된 변동 및 특정 처리의 변동이 일어난다면 DAO속에서 해결할 수 있다. 

 

Service가 정보를 가공하는 과정을 '비즈니스  로직을 수행한다'라고 하며 Service는 비즈니스 로직을 수행하고 DB에 접근하는 DAO를 이용해 결과값을 받아온다.  

  (비즈니스 로직은 결국 유저가 원하는 행동을 코드로 만든 것이라 코드가 자주 변경되므로 품질이 중요하다.

      생산성, 품질 관련 이슈) 

 

 Service는 결국 Repository에서 얻어온 정보를 바탕으로 데이터를 가공해 요청한 곳으로 정보를 보낸다.

직접 controller에서 DB에 접근해 정보를 얻고 가공하는 것은, 정보를 가공하는 과정에서 저장된 원본의 정보가 손실될 우려가 있기에 위험한 작업이라, 정보 변동의 위험이 큰 로직인 Service단에서 진행하는 것이다. 

 

 

이러한 전체적인 구조는 성능 이슈 및 생산성, 품질 등 다양한 부분과 관련을 맺고 있으며 효율적으로 적재적소에 코드를 사용해서 구현하는 것이 중요함을 알게 되었다.  또한 이 부분에 대해서 더욱 자세하게 공부해야할 필요성이 있다고 느낀점이 궁금한 부분을 넘어서 MVC등 다양한 영역과 맞물려있는 것이다. 그래서 다음에 기회가 된되면 MVC Architecture를 공부해야겠다..