Spring MVC Architecture
서론
웹 개발에 있어서 자주 사용되는 MVC 패턴의 아키텍처와 MVC 패턴의 특징 및 비지니스 로직은 어디에서 구현해야하는지 등에 대해서 배워보겠습니다.
Spring MVC Architecture
MVC 패턴이란 사용자의 요청을 처리하고 다시 사용자에게 반환하는 과정을 3가지 역할 Model, View, Controller 로 구분해서 처리하는 개발 방법을 의미합니다.
MVC 패턴 동작과정은 다음과 같습니다.
처음에 사용자가 컨트롤러로 데이터를 요청하거나 처리할 데이터를 전송합니다. 컨트롤러는 해당 요청 처리를 위해 모델을 호출하고, 모델은 데이터를 처리하여 다시 컨트롤러에게 반환합니다. 컨트롤러는 반환받은 데이터를 이용하여 다시 뷰(사용자)로 리턴합니다.
그럼 위 MVC 패턴이 어떤식으로 패키지 구성이 되는지 알아보겠습니다.
위 그림에서 초록색 영역은 ModelAndView 작업이 핵심입니다. 반면 보라색 영역은 DataBase 와 관련된 작업 구역을 나타냅니다.
위 그림을 잘 기억해야합니다. 스프링 프레임워크의 패키지 구조는 대부분 위와 동일합니다. Repository 는 DAO 라는 명칭으로 쓰기도하며, Domain Class 는 VO, DTO 를 나타냅니다. View 는 JSP 같은 사용자에게 직접 보여지는 화면단을 의미합니다.
위 그림을 토대로 패키지 구성을 해본다면 아래와 같습니다.
위 패키지 구성 방식은 보통 웹 개발을 할때 주로 사용하는 방식과 유사합니다. 회사마다 개인 스타일마다 조금씩 구성하는 방법이 다르지만 가장 핵심은 모듈 개발을 할 때 Repository, Service, Controller, Domain class 로 이루어 진다는 것입니다.
보통 비지니스 로직은 Service 단에서 구현하는데 왜 그런지는 밑에서 자세하게 다루도록하겠습니다.
그럼 먼저 MVC 패턴의 큰 구조와, 전체적인 흐름을 배웠으니, 스프링에서 내부적으로 어떻게 동작하는지에 대해서 다뤄보겠습니다.
세부적인 동작과정
위 그림의 동작과정을 글로 풀어 써보겠습니다.
사용자의 요청이 들어오면 DispatcherServlet 이 HandlerMapping 을 통해 사용자 요청에 부합하는 컨트롤러를 찾습니다. 그리고 DispathcerServlet 이 HandlerAdapter 를 통해 사용자 요청에 부합하는(요청 URI 와 동일한) 핸들러 메서드(HandlerMethod = 컨트롤러 메서드) 를 찾습니다.
HandlerAdapter 는 HandlerMapping 에서 찾은 컨트롤러에서 그 안에 있는 여러개의 메서드 중에서 클라이언트 요청을 처리하기에 가장 적합한 메서드를 찾아주는 역할을 합니다.
그리고 HandlerMethod 에서 사용자 요청을 처리하기 위해서 Service 와 Repositort(DAO) 를 거쳐 DB 작업을 한 뒤에, 처리된 요청 데이터를 받아서 HandlerAdapter 메서드에게 반환합니다.
이때 반환되는 정보가 ModelAndView 객체 입니다. 그리고 이 ModelAndView 객체를 다시 DispatcherServlet 에게 반환한 다음 DispatcherServlet 은 뷰 리졸버(ViewResolver) 를 통해서 적합한 View 를 찾아 사용자 페이지에 응답 데이터를 보여주게 됩니다.
ViewResolver 가 View 를 찾는 방식은 스프링 설정 파일에서 bean 태그안에 InternalResourceViewResolveer를 등록을 해야하고, @RequestMapping을 통해 반환(return)된 값과 beans property 안에 있는 prefix와 suffix의 value 값인 .jsp를 합쳐서 View 파일을 찾습니다.
즉,
prefix+return값+suffix값으로 적합한 View 를 찾습니다.
이번엔 왜 스프링 프레임워크 MVC 패턴을 사용할 때 비지니스 로직(Business Logic) 을 Service Layer 에서 구현해야 하는지에 대해서 다뤄보겠습니다.
비지니스 로직 구현은 서비스 계층에서 실시
회사 입사를 하고, 프로젝트 코드들을 보면 운 좋으면 오래된 프로젝트 소스를 보다가 모든 비지니스 로직 코드가 컨트롤러 단에서 구현된 경우를 볼 수 있습니다.
운 좋다고 표현한 이유는, 안좋은 코드들도 봐야 왜 안좋은지, 왜 이렇게 사용하면 안되는지에 대해서 더 깊게 생각할 기회가 될 수 있고, 경험이 될 수 있기 때문에 이렇게 표현했습니다.
비지니스 로직을 다른 요청 URI 에서도 사용해야하는 경우가 생길 수 있습니다. 만약 비지니스 로직 코드가 컨트롤러에 구현되어있는경우, 다른 컨트롤러의 핸들러 메서드에서 똑같은 로직코드를 구현해야하니 중복 코드가 발생하고 재사용성이 줄어듭니다.
즉, 비지니스 로직을 서비스 구현체에서 구현하는 이유가 바로 확장성과 재사용성 그리고 중복 코드의 제거입니다.
Service 는 Interface 로 구현되며 보통 Repository(DAO) 와 1:1 매핑입니다. 보통 EventService Interface 를 생성하면, 구현체도 대부분 1개만 구현됩니다. 그럼에도 불구하고 Interface 를 사용하는 이유는 다형성(Pholymorphism)과 낮은 결합도(Decoupling) 때문 입니다.
이에 대한 자세한 내용은 링크로 대체하겠습니다.
서비스와 리포지토리 계층이 1:1 매핑인 이유도 확장성 때문입니다. 서비스 계층에서 비지니스 로직이 확장되어도 다른곳에 부작용(Side Effect)이 없기 때문입니다.
그럼 스프링 프레임워크 MVC 패턴을 사용함으로써 얻는 장점과 단점은 무엇인지 알아보겠습니다.
장점
- 동시 다발적 개발(simultaneous multiple) : 백엔드 개발자와 프론트 엔드 개발자 혹은 퍼블리셔가 동시 다발적으로 개발할 수 있다.
- 서로 관련있는 기능을 하나의 컨트롤러로 묶거나 특정 모델과 관련있는 뷰를 그룹화할 수 있습니다.
- 개발 용이성
단점
- 코드 네비게이션 복잡
- 코드 일관성 유지를 위해 노력이 필요함
- 높은 러닝
결론
스프링 프레임워크 MVC 패턴에 대해서 다뤄봤습니다. 웹 개발자로 시작하실 분들, 신입 프로그래머라면 면접에서도 나올만한 내용이므로 꼭 알아 두어야합니다. 또한 MVC 패턴을 왜 사용하는지에 대해서 잘 몰랐던 분들도 이번기회를 통해 머릿속에 다시 정리하는 시간을 가졌으면 합니다.
