반응형

MVC 패턴의 필요성

디자인 패턴을 알기 전에는 하나의 클래스 안에 온갖 코드가 존재했었습니다. 기능별로 그리고 성격에 따라 아무리 모듈화 하였다고 한들, 예를 들어 버튼 컨트롤의 이벤트에, 온갖 모듈들이 뒤죽박죽 섞여 지저분한 코드로 가득했습니다. 이러한 코드는 개발자 본인이 유지보수하기에도 복잡하고, 다른 개발자가 투입되면 분석하기가 어렵고 유지보수 하기에 정말 막막해질 것입니다.

하지만 MVC 패턴이 적용되면 어떨까요? 우선 MVC 패턴에 대해 간단히 요약하면 아래와 같습니다.

Model: 어플리케이션의 데이터, 자료를 의미합니다.
View: 사용자에게 보여지는 부분, 즉 유저 인터페이스(User interface)를 의미합니다.
Controller: Model과 View사이를 이어주는 브릿지(Bridge)역할을 의미합니다.

즉, 역할에 따라 확실하게 분리하여 유지보수를 용이하게 그리고 프로그램의 확장성과 유연성을 높이기 위한 기법입니다. 데이터가 추가되면 Model 부분만 수정하고, UI가 수정되면 View 부분만 수정합니다. 물론 Controller는 두 부분을 관장하기 때문에 일부 수정이 필요하긴 합니다. 하지만 기존처럼 메인 다이얼로그/폼에서의 무분별한 하드 코딩이 필요 없다는 것이죠.

일단, MVC 패턴은 이렇습니다. 그래도 감이 안오실 것 같습니다. 제 설명이 부족하기도 하고, 사실 글보다는 코드를 보는것이 제일 좋은 방법입니다. 본문에 이어 예제 코드도 다룰 예정이니, 같이 읽어주시면 좋을 것 같습니다.

Model-View-Controller

모델-뷰-컨트롤러에 대해 좀 더 자세히 알고 넘어가겠습니다.

모델(Model)

프로그램에 사용되는 데이터를 의미하며 데이터베이스(DB), 상수, 문자열과 같은 변수들, 비전 프로그램이라면 카메라 정보와 같은 것들이 해당됩니다. 모델에는 뷰나 컨트롤러의 정보가 전혀 없습니다. 단지, 정보만 반환하거나 설정할 수 있습니다.

뷰(View)

다이얼로그에 존재하는 텍스트박스, 라벨, 버튼 등 사용자 인터페이스(User interface) 요소들을 의미합니다. 사용자가 제어하고 데이터를 확인할 수 있는 영역입니다. 뷰에서는 별도의 데이터를 보관하지 않습니다. 뷰에서 입력받고 출력해주는 모든 데이터는 모델을 사용해야합니다.

컨트롤러(Controller)

모델과 뷰를 관장하는 브릿지(Bridge)역할을 수행합니다. 사용자가 버튼을 클릭하면 이벤트는 뷰에서 발생하지만 내부 처리는 컨트롤러에서 관리하는 것입니다. 또한, 입력이 발생하면 이에 대한 통지를 담당합니다.

위 MVC를 다이어그램으로 표현하면 다음과 같습니다.

MVC 패턴 다이어그램

 

반응형