개발을 하는 사람이라면 꼭 알아야 하는 MVC 패턴에 관해 정확히 정리해보고자 노력했다. 실제 개발을 하면서 어떻게 돌아가는 것인지 파악하는게 가장 좋겠지만, 그 이전에 이론을 정리해보고자 한다. 우선, 디자인 패턴이 무엇인지부터 간략하게 정리하며 본 포스팅을 시작한다.
📝 디자인 패턴?
디자인 패턴은 개발 과정에서 공통적으로 발생하는 문제를 해결하기 위해 일반적인 해법과 작명법과 같은 여러 설계 노하우를 축적하고 그 방법에 이름을 붙여 이 후에 재사용하기 좋은 형태로 특정 규약을 만들어 정리한 것을 의미한다.
사실, 간단한 프로젝트 같은 경우는 코드의 양이 많지 않기 때문에 이런 디자인 패턴이 필요하지 않은 경우가 많다. 그러나, 프로젝트의 규모가 비대해지고 시간이 많이 흐르게 되면 협업하는 다른 개발자의 코드는 물론 자신의 코드도 이해하지 못하는 경우가 생기기 마련인데, 디자인 패턴을 사용함으로써 패턴대로 대부분의 코드가 전개되고 수정에 열려있는 구조이기 때문에 개발자의 입장에서 코드를 이해하고 수정하는 시간이 단축되어 유지보수 비용이 줄어들게 된다.
패턴에 따라 영역을 나눠 코딩을 하게 되면 역할에 따라 필요한 영역에 필요한 코드만 추가되니 코드의 가독성도 올라가고, 테스트와 유지보수 역시 편리해질 것이다. 또한 디자인 패턴은 객체 지향적으로 문제를 해결하는 경우가 많기 때문에 자바, 코틀린, C++과 같은 객체 지향 언어를 사용하고 있다면 대부분의 디자인 패턴을 환경을 가리지 않고 쉽게 구현 할 수 있다.
그렇다고 해서 어떤 디자인 패턴을 모든 경우에 사용하는 것이 옳은 것은 아니다. 디자인 패턴의 사용은 코드 및 클래스 양의 증대를 의미하고 이는 개발 복잡도를 높이기 때문에 지금 문제가 있거나 앞으로 문제가 발생할 경우가 없다고 판단되면 디자인 패턴대로 구현할 필요가 없다.
즉, 선택한 디자인 패턴이 자연스럽게 해당 프로젝트의 코드에 녹아들 수 있는지 깊은 고찰이 필요하고 상황에 따라 알맞은 디자인 패턴을 적용해야 한다.
🙄 MVC 패턴?
Model - View - Controller 의 합성어
MVC는 프로그래밍 디자인 패턴 중 하나로, 어플리케이션을 구성할 때 모델, 뷰, 컨트롤러 세 가지 역할로 구분한 패턴을 의미한다. 한 요소가 다른 요소들에게 영향을 주지 않도록 설계하는 것이 중요하다.
🤗 자세히 알아보자
📌 Model
화면에 사용할 데이터를 저장하고, 로직까지 처리하는 공간을 의미한다.
데이터베이스, 상수, 문자열과 같은 변수들이 보통 이 영역에 속해있다. 어떤 애플리케이션이 목표하는 작업을 원활하게 수행할 수 있도록 필요한 요소들이 저장되어 있다.
또, 단순히 데이터 덩어리만을 가지고 있는 것은 아니다. 예를 들어, 축구 게임을 개발한다고 가정해보자.
위와 같이 사용자가 축구공을 차면, 축구공의 좌표는 계속해서 변화될 것이다. 변화된 값을 컨트롤러와 뷰에 전달하는 것이 모델의 역할이라고 생각하면 쉽게 받아들일 수 있을 것이다. (아마도)
주의할 점은, 모델은 데이터와 관련된 코드들만을 모아두는 역할을 담당하고 있기 때문에, 모델 역할을 담당한 코드는 컨트롤러, 뷰와 관련된 코드가 존재해서는 안된다.
📌 View
사용자에게 보여지는 화면만을 구성한 곳을 의미한다.
말 그대로의 의미이다. 사용자가 보는 화면을 의미하는데, 모델에서 데이터의 변화값을 컨트롤러에 전달하면, 컨트롤러가 뷰로 전달하여 뷰는 변화를 화면에 나타내어 사용자에게 보여주는 역할을 수행한다.
위의 모델과 동일하게 주의할 점은, 뷰에서는 비즈니스 로직이 일절 포함되어선 안되고, 오직 컨트롤러를 통해 받은 데이터로만 화면을 구성해야 한다. 한마디로 출력을 전문적으로 처리하는 역할을 맡았다고 생각하면 된다.
📌 Controller
사용자의 요청을 받아 뷰, 모델을 변화시키는 알고리즘과 소스코드가 위치한 곳을 의미한다.
모델과 뷰 사이를 중개해주고, 데이터의 흐름을 제어하는 역할을 담당한다. 아주 쉽게 이야기하면, 뷰와 모델에게 명령을 하는 녀석이라고 생각하면 된다.
사실 제일 짧게 설명했지만 코드는 가장 긴 녀석
🤔 왜 쓰는건데?
코드가 얘처럼 되는걸 막으려구요.
- 비교적 구조가 단순하여 많은 플랫폼에서 사용한다.
먹고 살기 위해 써야한다. - 클래스, 메소드를 분리해 다른 프로젝트에서 사용하기 편리하다. 즉 코드 재사용이 용이하다.
- 여러 인터페이스에 적용하기 편리하다.
- 스파게티 코드화를 막음으로서 유지보수가 용이해진다.
- 요소를 명확히 나눔으로서 디자이너, 프로그래머의 협업이 진행될 때 공동 작업이 쉬워진다.
😨 이런 점은 아쉽다
-
컨트롤러에 소스 코드가 집중되는 경향이 있다. 즉, 컨트롤러의 의존성이 올라갈 가능성이 높다. (안드로이드의 경우 액티비티에 코드가 대부분 집중되어 있는 것을 확인할 수 있다.)
-
프로젝트가 커지고 복잡해질수록 뷰 - 모델간의 의존성이 커지면서 디자인 패턴이 모호해져 코드 재사용성이 하락되고 유지보수가 어려워진다.
-
설계 단계에서 클래스가 많아져 구조가 복잡해질 우려가 있고, 시간도 오래 소요된다.
참고 및 출처
