Intro
백엔드 공부를 처음 시작할 때, MVC패턴으로 짜면 좋다 라는 인터넷 글을 보고 자연스럽게 MVC패턴을 적용해가려고 노력하며 코드를 작성하게 되었다. 그런데 42서울의 마지막 팀 과제를 하는 과정에서 한 팀원이 "MVC패턴을 왜 써야하는지 자기는 모르겠다" 라는 말을 하였고, 나는 그에 대해서 합당하게 설명을 하지 못했던 경험이 있다. 따라서 나는 정확히 왜 사용하는지 알고 쓰는 것이 아니라, 그냥 남들 다 쓰니까 쓰는거구나 라는 생각이 들었고, 사용방법과 이유에 대해서 자세히 생각해봐야겠다는 생각을 하게 되었다.
MVC패턴
MVC패턴이란, Model + View + Controller로 나누어 설계하는 디자인 패턴이다. 디자인패턴이란, 위키피디아에 따르면 프로그램에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 과거 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적하여 이름을 붙여, 이후에 재사용하기 좋은 형태로 특정의 규약을 묶어서 정리한 것이다. MVC패턴은 이러한 디자인 패턴 중에서도, 웹 개발에서 유명한 패턴 중 하나이다. 그렇다면 MVC패턴의 특징과 장단점을 알아보도록 하자.
MVC패턴의 특징
제일 처음 MVC패턴을 알아보게 되었을 때, 왜 이걸 사용하는거지? 라는 궁금증이 들었다. 가장 큰 특징으로는 어플리케이션을 세 개의 영역(Model, View, Controller)으로 나누어서 사용자 인터페이스로부터 비즈니스 로직을 분리하여 시각적 요소나 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있다는 장점이 있다.
즉 쉽게 말해서, 각자에게 역할을 부여해서 본인이 맡은 일만 잘 하게 하자! 이다.
위 사진의 구조를 순서대로 설명하자면,
1. 유저가 Controller를 조작한다.
2. Controller는 서비스를 위해 Model을 호출한다.
3. Model은 요청에 대한 처리를 진행한 후 Controller에게 반환한다.
4. Controller는 Model이 리턴한 결과를 View에게 전달한다.
5. View는 데이터를 반영하여 이 결과를 유저에게 전달한다.
조금 더 쉬운 일상용어로 한 번 이를 풀어보고자면, 나는 현재 A라는 장소를 가기 위해 지도 어플을 이용하려고 한다. 이 때 나(유저)는 어플에게 A로 가는 최단 경로를 요청한다. 그렇다면 어플의 Controller는 이 요청을 받아서 Model에게 전달하면, Model은 A로 가는 최단 경로를 내부 비즈니스 로직을 통해 파악하고 이를 Controller에게 전달한다. 결과를 전달받은 Controller는 View에게 이를 전달하고, 어플리케이션에는 내가 원하는 A로 가는 최단 경로를 나타내게 된다.
구조적인 부분을 설명했으니, 각 역할에 대한 부분을 조금 더 자세히 알아보도록 하자.
Model
Model이란, 데이터와 정보들의 가공을 책임지며, 내부 비즈니스 로직을 처리하기 위한 구성요소(컴포넌트)이다.
- 컨트롤러가 호출할 시, DB와 연동하여 사용자의 데이터를 다루며 비즈니스 로직을 처리함
- 데이터의 추출, 삭제, 저장, 업데이트 등의 역할을 수행한다(직접적인 데이터를 처리)
Model의 규칙
모델을 설계하기 위해서는 따라야 하는 몇 가지 규칙이 존재한다.
- 사용자가 편집하고자 하는 모든 데이터를 가지고 있어야 한다.
- 요청에 대한 데이터를 제대로 처리하기 위해서는, 당연히 요청받는 모든 데이터에 대한 정보를 가지고 있어야 이를 처리할 수 있다고 생각한다.
- View나 Controller에 대해서 어떠한 정보도 알지 말아야 한다.
- 이 부분은, Model은 결국 View나 Controller에 의존적이지 않아야 한다는 뜻으로 해석했습니다. 데이터에 대한 처리를 담당하기 때문에 자신이 맡은 부분만 확실하게 처리하면 되지, A를 통해 들어왔을 때와, B를 통해 들어왔을 때 다르게 반응한다면 역할 구분이 제대로 되지 않은 것이라고 생각합니다.
- 변경이 일어나게 되면, 변경 통지에 대한 처리방법을 구현해야 한다.
- 이 말은, 만약 내가 TODO리스트에 현재 "공부하기" 라는 내용만 있을 경우, 당연히 화면 상에는 "공부하기" 만 떠 있을 것입니다. 하지만 요청을 통해서 "밥먹기" 를 추가한다면, 단순히 Model에서만 추가되는 것이 아니라 이를 View 및 Controller에게 전달하여 사용자에게 "밥먹기" 라는 부분이 추가된 것을 알 수 있도록 해야 한다.
View
View란, 사용자(유저)에게 보여지는 부분, 즉 유저 인터페이스(User Interface)를 뜻한다.
- MVC패턴은 여러 개의 View를 가질 수 있다.
- 사용자와 상호작용하며 컨트롤러로부터 받은 모델의 결과값을 사용자의 화면에 출력한다.
- 모델에서 받은 데이터는 별도로 저장하지 않는다.
View의 규칙
- Model이 가지고 있는 정보를 따로 저장하면 안된다.
- 결국 MVC패턴의 주 목적인, 역할 분리를 위해서는 View와 Model이 서로 의존하지 않아야 하기 때문에 따로 데이터를 저장하지 않아야 한다.
- Model이나 Controller와 같이 다른 구성요소들을 몰라야 한다.
- Model에서의 설명과 비슷하다. 위와 같이 결국 독립적으로 사용되어야 한다는 것이다.
- 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야 한다.
- 변경이 일어난다면, 당연히 사용자에게 보여지는 부분이 달라져야 한다.
Controller
Controller는 Model과 View 사이를 이어주는 다리 역할을 합니다. Model이나 View는 독립적으로 자신 이외를 모르기 때문에, 이를 이어주는 컨트롤러가 필요한 것이다.
- Model이 데이터를 어떻게 처리할 지 알려주고 처리된 데이터를 View에 전달하는 역할을 한다.
- 사용자(유저)로부터 View에 요청이 있다면, Controller는 해당 업무를 수행하는 Model을 호출해서 데이터를 처리한다.
Controller의 규칙
- Model이나 View에 대해서 알고 있어야 한다.
- Model과 View에서는 서로 몰라야 한다는 이야기를 했지만, Controller는 다르다. 어느 View에서 요청이 들어왔으며, 이를 처리하기 위해 어느 Model을 호출해야할지를 생각해야 하기 떄문이다.
- Model이나 View의 변경사항을 모니터링 해야 한다.
- Model이나 View에서 변경이 일어나면 변경 통지에 대한 처리방법을 구현했다. Controller는 이 통지를 서로에게 전달해야 하기 때문이다.
MVC패턴의 장,단점
MVC패턴의 장점
- 역할별로 코드를 분리하기 때문에, 가독성 및 코드의 재사용이 증가한다. -> 유지보수 및 확장성 측면에서 도움이 된다.
- 각 구성요소들을 독립시키기 때문에, 협업 시에 의존을 생각하지 않고 맡은 부분의 처리만이 가능해진다.
- 이 부분이 엄청난 장점이라고 생각한다. 동시에 개발을 진행할 수 있다는 것은 시간적인 측면에서 많은 부분을 save할 수 있을 것이라 생각한다.
MVC패턴의 단점
- 사실 Model과 View의 측면에서는 의존적으로 독립되어 있다고 표현할 수 있지만, 이를 Controller을 통해서 연결되어 있어서 100% 독립적이다고 할 수 없다.
- 그렇다면 프로젝트가 대규모여서 다수의 View와 Model들이 Controller을 통해서 연결되기 때문에 Controller가 불필요하게 커질 수도 있다.
- 이러한 점을 보완하기 위해, MVP, MVVM, Flux, Redux 등 다양한 패턴들이 존재한다.
웹 개발 디자인 패턴의 기초라 할 수 있는, MVC 디자인패턴을 학습해 보았다. 작성하면서 알게 된 점은, 현재 내가 진행중인 프로젝트에서는 DTO나 DAO, Service 로직 등이 존재하는데 그렇다면 이것은 단순 MVC패턴이 아니라, 조금 더 확장된 디자인 패턴인가? 하는 의문이 들었다. 그런 것도 모르고, 팀 과제 당시 MVC에 대해서 뭔가 아는 척을 했다는 느낌이 들었다. 이후 포스팅에서는 DTO, DAO 등 추가적인 부분들을 조사하며 기존 MVC패턴이 아니라면, 어떠한 이유로 사용하게 되었으며, 어떻게 발전된 것인지 조금 더 공부해보고 싶다.
📒 작성된 내용 중에 틀린 부분이 있다면 언제나 지적해주시면 감사하겠습니다.
Reference
https://opentutorials.org/course/697/3828
https://velog.io/@seongwon97/MVC-패턴이란
https://velog.io/@eunhye_k/MVC-패턴의-이해
'Back-End' 카테고리의 다른 글
[AWS] AWS, EC2, S3란 무엇일까? (0) | 2023.11.10 |
---|---|
[Java] Long? long? Wrapper Class에 대하여 (4) | 2023.11.09 |
[Spring] 스프링 DB 접근 기술 (0) | 2023.11.08 |
[Backend] REST, REST API, RESTful (0) | 2023.10.08 |
[Backend] 백엔드 공부 시작 (0) | 2023.10.05 |
댓글