웹 개발을 한다면 MVC패턴이라는 말을 한번씩 듣게 될것이다. 이것 외에도 다른 패턴들이 있지만 필자는 Spring framework를 사용하기 때문에 MVC패턴이 무엇인지에 대해서 알아보자.
MVC 패턴을 사용하게된 이유
너무 많은 역할
하나의 서블릿, jsp만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게 되고, 결과적으로 유지보수가 어려워진다. 비즈니스 로직을 호출하는 부분이 변경되도 해당 코드를 손대야 하고, UI를 변경할 일이 있어도 비즈니스 로직과 함께있는 파일을 건드려야 한다. 자, 여기서 UI에 버튼을 하나 변경하기위해 html을 수정한다 했을때에 수백줄의 자바코드가 함께 뒤엉켜 있다고 생각해보자... 그 반대도 마찬가지다.
서로다른 라이프 사이클
뷰와, 비즈니스 로직에 라이프 사이클은 다르다. 예를 들어 UI를 일부 수정하는 일과 비즈니스 로직을 수정하는 일은 각각 다르게 발생할 가능성이 매우 높고, 대부분 서로에게 영향을 주지 않는다. 이렇게 서로 다르게 움직이는 라이프 사이클을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않다. 그리고 코드의 복잡도가 올라가 인수인계 하기도 매우 어렵다.
기능 특화
특히 JSP같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있다. 그렇기에 이 부분에 업무만을 담당하는 것이 가장 효과적이다.
MVC 패턴 이란?
MVC 패턴이란 위의 문제점들을 해결하기 위해 만들어진 아키텍처 패턴이며, MVC패턴은 Model(모델) , View(뷰) , Controller(컨트롤러) 세 가지 구성 요소로 나뉜다. MVC 패턴을 성공적으로 사용한다면 아키텍처 패턴의 많은 장점들이 적용되며, 사용자 인터페이스로부터 비즈니스 로직을 분리해서 애플리케이션의 시각적인 요소나 그 뒷단에서 실행되는 비즈니스 로직을 서로 영향없이 고칠 수 있는 애플리케이션을 만들 수 있다.
모델(Model)
잠깐!
모델이라 하면 어떤 분은 DTO의 역할 즉, 클라이언트의 요청에 포함된 데이터를 담아 서버측에 전달하고, 서버측의 응답 데이터를 담아 클라이언트에게 전달하는 계층간(Controller, View, Business Layer, Persistent Layer) 전달자 역할을 떠올리시는 분들이 있을것이다. 그러나 모델을 문맥에 따라 여러 용어로 정의 할 수 있고 모델을 service, dao(Repository), dto(Domain) 까지 묶는 경우도 있다. 이번 글에서는 모델을 service, dao, dto를 포함하는것으로 설명할 것이다.
DATA, 정보들을 가공하는 컴포넌트를 말합니다.(애플리케이션의 정보, 데이터와 관련된 부분입니다)
- 내부 비즈니스 로직을 처리하기 위한 역할을 하며
- 주로 상태 변화를 처리한다.[최근에는 Entity, VO, Aggregate로 나뉘어서 관리합니다.(도메인 주도 설계)]
- 애플리케이션의 정보, 데이터를 나타낸다.
- 뷰나 컨트롤러의 정보를 전혀 가지고 있지 않는다.
- 단지, 정보만 반환하거나 설정을 할 수 있는 행동을 갖는 객체이다.
모델의 특징들
사용자가 사용하길 원하는 모든 데이터들을 가지고 있어야 한다.
즉, 유저의 정보, 게시판의 작성된 글의 정보, 사진의 정보와 저장위치 등... 을 가지고 있어야 한다.
뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
데이터의 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가져서는 안된다.
모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 변경 통지에 대한 처리방법을 구현해야만 한다.
이와같은 통보를 통해 뷰는 최신 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가.제거.수정할 수 있다.
뷰(View)
사용자에게 보여지는 부분이며, 데이터를 기반으로 사용자들이 볼 수 있는 화면이다.
- 웹에서는 웹 브라우저로 렌더링 되는 페이지가 해당된다.
- 컨트롤러가 전달해준 모델이 처리한 데이터를 받아서 합산하고 사용자(클라이언트)의 브라우저로 렌더링 되는 페이지이다.
- 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당한다.
뷰의 특징들
뷰에서는 별도의 데이터를 보관하지 않는다.
뷰는 사용자가 제어하고 데이터를 확인할 수 있는 영역입니다. 뷰에서 입력받고 출력해주는 모든 데이터는 모델을 사용해야 한다.
모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 한다.
뷰는 그저 데이터를 받으면 화면에 표시하고, 제어에 대한 통지를 해주는 역할을 한다.
컨트롤러(Controller)
모델과 뷰 사이를 이어주는 브릿지(일종의 중개자) 역할을 한다.
- 사용자가 버튼을 클릭하면 이벤트는 뷰에서 발생하지만 내부 처리는 컨트롤러에서 관리한다.
- 사용자의 요청(웹 브라우저로 들어오는 요청)을 가장 먼저 마주한다.
- 컨트롤러는 사용자의 요청에 맞는 비즈니스 로직을 실행하여 모델에 데이터를 담아준다.
- 처리한 모델의 값을 뷰에 전달해서 반환한다.
컨트롤러의 특징들
모델과 뷰에 대해서 알고 있어야 한다.
모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중개하기 위해 모델과 그에 관련된 뷰에서 알고 있어야 한다.
모델과 뷰의 변경사항을 모니터링 해야 한다.
모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 합니다. 또한, 애플리케이션의 메인 로직은 컨트롤러가 담당하게 된다.
MVC 패턴의 장점은 무엇인가?
- 프론트엔드와 백엔드를 독립적으로 나눌 수 있어 동시다발적으로 개발할 수 있다.
- 모델, 뷰, 컨트롤러로 책임 영역이 구분되고, 해당 영역에서의 집중도가 올라가 효율적으로 일을 처리할 수 있다.
서로 분리되어 각자의 역할에 집중할 수 있게하여, 그 상태로 개발을 진행하고 애플리케이션을 그렇게 만든다면 유지보수성, 애플리케이션의 확장성, 그리고 유연성의 증가, 중복코딩의 문제점이 사라지게 됩니다.
유연성이란?
여기서 말하는 유연성이란 클라이언트의 새로운 요구사항에 대해 최소한의 비용으로 보다 유연하게 대처할 수 있는 것을 말한다.
MVC 패턴의 단점
MVC패턴의 단점때문에 mvc패턴을 사용하지 않을 일은 없기때문에 그냥 알아만 두자.
- 코드의 전체적인 처리 과정을 이해하기 위한 배경지식이 필요하다.
- 모델, 뷰, 컨트롤러가 각자의 역할에서 벗어나지 않도록 주의깊게 관리해야 한다.
- 완벽한 프로그램이란 없듯이 MVC패턴에도 한계가 존재한다. 복잡한 대규모 프로그램의 경우 다수의 뷰와 모델이 컨트롤러를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생한다. 복잡한 화면을 구성하는 경우에도 동일한 현상이 발생하는데 이를 'Massive-View-Controller' 라고 한다.
이런 문제점들을 보안하기 위해 다양한 패턴들이 파생되었으나 MVC패턴에 대해 공부하는 글이므로 다른 패턴들이 있다는 것에 대해서만 알아두자.
마무리
마무리 요약
결국 MVC패턴은 개발하기 좋은 즉, 각각의 구역별로 역할을 분담하여 개발하기 좋은 환경을 만들기 위한 패턴이라는 것이다.
다시한번 되세기기
- 모델, 뷰, 컨트롤러 별로 각자 자기가 맡은 영역에 대해서 집중할 수 있다.
- 개발 시에 발생하는 다양한 에러의 원인과 내용들을 좀 더 쉽게 파악할 수 있고, 시행착오가 줄어들어 개발 시간이 단축됩니다.
- 협업시에 공통된 아키텍처를 공유할 수 있어 의사소통이 편해지고, 시스템의 구조를 이해하는 것이 쉬워 새로운 개발자가 온다 하더라도 프로그램 내에 체계적인 구조와 패턴을 활용하여 작성된 코드 덕분에 좀 더 쉽게 프로그램을 이해할 수 있다.
참조
'Framework > Spring' 카테고리의 다른 글
| Spring framework 는 무엇인가 (0) | 2022.05.17 |
|---|---|
| Maven의 설정파일 Pom.xml을 알아보자 (0) | 2022.05.15 |
