Spring 의 MVC 구조

Sprint3 까지 구현했던 그룹웨어를 sprint4에서 리팩토링을 하면서 이사님께서 CLI 프로그램을 새로운 과제로 내셨고,
해당 과제는 Controller와 Service의 완벽한 분리를 위한 과제라는 것을 알게 되었다.

리팩토링을 하기전에 기능 구현에만 집중했던 결과, Controller와 Service의 역할에 대해서 진지하게 고민하지않고,
되는대로 기능만 잘 동작하길 바랬던 그대로 코드들이 정리되지 않아 있었기에, 매우 고생을 하고 있다.

그래서 Spring에서 MVC 구조에 따른 각각의 역할에 대해서 명확하게 정리하고 넘어가야겠다는 생각을 (이제서야) 하게 되었다.

Controller :
처리해야 할 데이터를 브라우저에게 받는다. (Request, Session 등)
담당할 service를 선택하여 호출한다. (적절한 서비스를 호출하는 역할)
처리한 데이터를 다음 페이지에서 볼 수 있게 셋팅한다. (Model에 attribute 추가)
이동할 페이지를 리턴한다. (String으로 뷰로 연결해줌)

Service (Model) :
데이터를 받아 비지니스 로직을 처리한다. (글을 쓰거나, 글을 읽거나, 글을 지우거나 하는 모든 것들)
DB의 활용이 필요한 경우 해당 처리를 하는 DAO를 호출한다. (DAO를 쓰지않는다면 Mapper로)

View :
사용자에게 초기화면을 보여준다.
사용자가 입력한 데이터를 컨트롤러에게 보낸다.(브라우저와 HTTP 통신을 통해서)

여기에서 드는 의문점은 Controller와 Service를 왜 구분하느냐 이다.
MVC구조를 따르지 않는 웹 프로젝트들은 Controller와 Service의 구분이 없고,
뷰도 함께있다는 것이 가장 큰 특징이라고 생각하고,
그렇게 개발된 웹 프로젝트들도 “일단은” 잘 굴러가기 때문에 의문이 들었다.

MVC 구조로 개발하는 이유가 도대체 무엇인가!

그것은 쉬운 유지보수와 완전한 객체지향인 것 같다.

하나의 객체가 정말 하나의 일만 완벽하게 수행한다면,
일하는 방식을 수정해야할 때, 객체 하나만 바꾸면 되지만,

하나의 객체에 여러 가지 논리가 섞여서 앞의 논리가 뒤의 논리에 영향을 미치는
상태라면, 부분을 변경하기 위해서 전체를 다 확인해야하는 번거로움이 있다.

그렇다면,

정말 단순하고, 유지보수할 건덕지도 없는 아주 일회용적이고 작은 프로젝트는

굳이 MVC 구조로 작성할 필요가 없을까?

개인적으로는 없을 것 같다이다.

MVC 구조로 프로그래밍을 작성하려는 노력은 개발자에게 필수적이지만,

천재적으로 기능을 잘 나누고 빠르게 작업을 할 수 있는 개발자가 아니라면,

MVC 구조를 만들어가는 것은 분명 그만큼 시간이 필요하다.

유지보수할 이유도, 필요도 없는 작은 프로젝트를 MVC 구조로 만들 필요는
없는 것 같다.

마치 학부시절에 과제들을 MVC 구조로 만들어 간적이 없는 것 처럼.
(기능이 하나라서 나눌 수가 없었던 걸까)