[Spring MVC 프로젝트 리팩토링] 4. @Service, 비즈니스 로직 분리

📄 관련 글

---

• [Spring 웹 프로젝트] 숙박 플랫폼 GOING
• [Spring MVC 프로젝트 리팩토링] 1. 국비지원교육의 한계
• [Spring MVC 프로젝트 리팩토링] 2. SqlSessionFactory -> SqlSessionTemplate
• [Spring MVC 프로젝트 리팩토링] 3. 의존성 주입 수정
• [Spring MVC 프로젝트 리팩토링] 4. @Service, 비즈니스 로직 분리
• [Spring/스프링] JUnit을 이용한 단위 테스트, @Test
• 웹프로젝트 문자인증 구현하기 with 네이버 클라우드 플랫폼
• [Java/자바] 날짜-Date의 모든 것 (현재-내일 날짜, Date 포맷 변환, 날짜 차이 계산, 더하기, 빼기)
• 자바 세미 프로젝트 - 숙박 플랫폼 GOING

 

 

 

⚡️리팩토링 Before -> After

---

📌 Before

이 GOING 프로젝트는 기존 model2 프로젝트를 Spring 프로젝트로 바꾼 프로젝트입니다.

 

스프링 형태로 작동하도록 했지만 @Controller, @Service, @Repository 별 코드의 분리가 전혀 이루어져있지 않았습니다.

 

Service 파일은 별도로 없었으며 Controller와 Dao 파일만 존재했습니다.

---

📌 After

우선 서비스 패키지를 만들어 비즈니스 로직을 컨트롤러부터 모두 분리해주었습니다.

 

그 후 역할에 맞게 코드를 재배치해주었습니다.

 

 

 

⚡️리팩토링 이유

---

📌  어노테이션 별 역할

스프링에서 빈 등록을 위해 주로 선언하는 어노테이션은 @Controller, @Service, @Repository 3가지가 있습니다.

 

Controller는 사용자의 요청을 받고, 요청에 대한 응답을 전달하는 역할,

Repository는 Dao 파일로 데이터베이스와 관련된 작업을 하는 역할,

그리고 Service는 그저 "비즈니스 로직"과 관련된 역할로 어렴풋이 이해하고 있었습니다.

 

처음에는 Service의 필요성에 대해 이해가 잘 안 되어 굳이 중간에 다리를 하나 더 놓을 필요가 있나 생각하며

인강도 보고 여기저기 검색도 해보며 깨달음을 얻게 되었습니다.

 

그렇게 내린 결론은 다음과 같습니다.

 

1. Controller에는 요청과 응답에 대한 작업만 수행하는데, 요청에 대한 응답은 Service를 통해 모두 처리합니다.

2. Service에서는 하나 혹은 여러 Dao를 사용해 데이터를 처리하고, 로직을 통한 결과를 Controller에게 넘겨줍니다.

3. Repository에서는 들어온 데이터가 있다면 정리하고, DB 작업을 처리해서 결과를 Service로 넘겨줍니다.

 

그리고 Service에서는 여러 개의 Dao를 불러오다 보니 하나의 논리적 단위가 되었고,

이는 곧 하나의 트랜잭션이 되어 스프링 트랜잭션을 통해 문제 발생 시 롤백 등 후처리가 가능했습니다.

 

각 역할별 코드를 분리하니 여러 책임을 갖고 있던 모듈이 단일 책임을 갖게 되었고, 결합도를 낮출 수 있었습니다.

 

덕분에 각 모듈 별 JUnit을 이용한 단위 테스트를 수행하기 수월해졌고,

Service에서는 트랜잭션을 도입해 시스템 안정성을 높일 수 있었습니다.

 

이렇게 거의 완성된 프로젝트 코드 전체를 뒤엎는 고생을 하며 느낀 점은

"처음부터 열심히 공부해서 스노우볼 굴리지 말자"로 정리할 수 있을 것 같습니다.

 

가장 힘들었던 부분이지만 그래도 덕분에 스프링 구조에 대해 심도 깊게 공부할 수 있는 기회가 된 거 같아 그나마 다행입니다.