MVC 패턴

프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통적으로 발생하는 문제들을 해결하기위해 형식화 시킨 설계 방법을 소프트웨어 디자인 패턴이라고 부른다. 그 중 흔하게 사용되는 MVC(Model-View-Controller)패턴을 알아본다.

구성요소

MVC패턴은 이름에서 알 수 있듯이 3가지의 구성요소를 가진다.

모델(Model): 데이터를 가진 객체다. 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다. 어떤 MVC 구현에서는 통보 대신 뷰나 컨트롤러가 직접 모델의 상태를 읽어 오기도 한다.
뷰(View): 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어온다. 그 과정은 컨트롤러의 도움을 받는다.
컨트롤러(Controller): 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다. 그리고 컨트롤러가 관련된 뷰에 명령을 보냄으로써 모델의 표시 방법을 바꿀 수 있다. 모델과 뷰를 연결해 주는 역할을 가진다.

MVC%20%E1%84%91%E1%85%A2%E1%84%90%E1%85%A5%E1%86%AB%20469e5024c5244798b2f93d8e1ab4d81d/Untitled.png

MVC 패턴을 지키기 위한 5가지 규칙

모델은 컨트롤러와 뷰에 의존하지 않아야 한다.(모델 내부에 컨트롤러와 뷰와 관련된 코드가 있으면 안된다.)
뷰는 모델에만 의존해야 하고, 컨트롤러에는 의존하면 안된다.
뷰가 모델로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
컨트롤러는 모델과 뷰에 의존해도 된다.(컨트롤러 내부에 모델과 뷰의 코드가 있을 수 있다.)
뷰가 모델로부터 데이터를 받을 때, 반드시 컨트롤러에서 받아야 한다.

MVC 패턴의 유효성 검사

이 글은 정해진 규칙 또는 법칙이 아닌 필자의 개인적인 의견입니다.

MVC 패턴을 사용하는 애플리케이션에서 사용자 입력에 대한 유효성 검증을 해야되는 경우가 간혹 있다. 이런 경우 어디서 처리해주는 것이 좋을까? 유효성 검사는 가능하면 모든 레이어에서 하는 것이 안전하다. 언제 어떻게 잘못된 값이 흘러 들어갈지 예측할 수 없기때문이다. 그리고 뷰에서 미리 검증 과정을 거쳐 불필요한 데이터를 서버에 전송하는 것을 막을 수 있다면 네트워크의 오버헤드도 줄일 수 있다.

하지만 규모가 작은 애플리케이션의 경우는 로직 대비 검증 코드가 많아 오히려 코드가 지저분해질 수도 있고, 오히려 애플리케이션 실행에 불필요한 오버헤드가 발생할 수 있다. 만약 한 곳에서만 유효성 검사를 한다면 어디서 하는 것이 좋을까? 바로 모델이다. 컨트롤러에서 한다면 모델을 사용하는 과정에서 잘못된 값이 흘러들어 갈 수 있다. 또한 데이터의 생성, 수정, 삭제가 발생하는 경우 결국에는 모델을 거치게 되어있다.