[아키텍쳐 패턴] - MVC 패턴

오늘은 아키텍쳐 패턴에 첫번째 MVC패턴에 대해 알아 보겠다

 

MVC패턴이란

 

아키텍쳐 패턴의 종류중 하나로 View,Model,Controller 3가지로 구성된 패턴이다.

이렇게 구성요소만 보면 감이 안온다... 각 부분은 이름에 관련된 코드를 말하는 것인데 조금 더 자세하게 알아보자

 

 

뷰(View)

• 사용자에게 보이는 화면
• 웹개발에서 프론트앤드와 비슷한 느낌(HTML,CSS)
• 껍데기만 있는 상태

모델(Model)

• 화면에 사용할 데이터들이 저장되어 있는 곳
• 메모리에 데이터가 저장되어 있는 상태
• 특정 내용을 분기별로 나눠서 관리해야함 → 유지보수

컨트롤러(Controller)

• 뷰와 보델을 변화 시키거는 알고리즘 또는 소스코드가 위치한 곳
• ex) 버튼 뷰를 클릭 했을 때 특정 변수(모델)에 저장하는 명령 그 자체를 의미

 

 

 

 

대충이런 느낌이다. 3가지 오퍼레이션이 서로와 상호작용을 하는 형태인데, 요즘 예제 그림이 하도 많아서 내가 가장 이해하기 쉬웠던 그림으로 가져왔다.  일단 위의 과정은 이렇다.

 

1. 액션이 Controller로 입력이 됨
2. Controller는 받은 액션(데이터)을 Model로 전달
3. Controller에서 Model에서 가공된 데이터를 View로 전달하여 화면에 띄움

형식은 이러하다. 하지만 말과 과정만 안다고 해서 우리가 처음부터 MVC규칙을 100% 구현하기는 쉽지가 않다. 그리고 MVC는 각각 코드에 대한 규칙이 존재하는데 그것도 알아보자

 

• Model은 Controller와 View에 의존하지 않아야한다. (M안에 C,V관련 소스가 있으면 안됨)
• View는 Model에게만 의존하고 C에겐 의존하지 않아야한다.(V안에 M은 있어도 C는 있으면 안됨)
• Model에서 받은 데이터는 View에서 사용자마다 다른 정보를 보여줘야한다.
• Controller는 Model,View의 관련 코드 모두 존재할 수 있다.
• View가 Model에게로부터 데이터를 받을 때 Controller를 통해서 받아야함(M → V 안됨)

어찌보면 이 패턴상 당연한 말들이다. Controller는 View와 Model을 관장한다. Controller에 의해서 데이터를 가공하고 요청하며 응답하고 전달한다. 단 Model은 데이터들이 있는 창고 이기 떄문에 직접적으로 어디에 영향을 끼치지는 못하고 Controller가 데이터를 Model에 저장을 해두고 View에게 필요한거 있으면 빼다써! 그대신 허락을 받고 가져가..!?  이런 느낌이다.

 

MVC 패턴의 장/단점을 알아보자

 

장점

• 코드 재사용 용이 (특정 부분을 다른 프로젝트에서 사용 용이)
• 여러 인터페이스를 적용하기 편함
• 구조가 단순해 진입장벽이 낮고 범용적으로 사용

단점

• 역할이 너무 Controller 중심적임 (일이 편향 되었음)
• 위와 같은 이유로 프로젝트가 복잡해질 수 있다.

 

MVC는 상대적인 개념이기 때문에 설계도 쉽고 정형화 시키기가 편하다. 하지만 오히려  이런 부분 때문에 MVC안에 MVC가 생길 수도 있기 때문에 조심하여 설계하도록 해야한다.