오늘은 MVC 패턴에 대해서 이야기 해보고자 합니다. 가능한 짧고 간단하게 설명하고 싶은데, 잘 될지 모르겠네요. 출처는 제 뇌 입니다.
MVC 패턴은 다음의 약자입니다.
Model 모델
View 뷰
Controller 컨트롤러
세가지의 앞 글자를 따서, MVC 패턴 이라고 부릅니다.
개인적으로 볼 때, MVC 를 순서를 거꾸로 해서. Controller, View, Model 순으로 집중을 하면 이해가 쉽다고 봅니다.
먼저, 어떠한 호출을 가장 먼저 Controller 에서 받게 됩니다.
Controller 에서 View 를 호출하는 구조를 최초로 갖는게 특징입니다. 그렇지 않다면, 음...이 패턴은 MVC 라고 보기가 어렵습니다.
이 단순한 점으로, MVC 패턴을 구분하는 첫 번째 단서가 됩니다.
사실 단순한 이유입니다. 컨트롤러 는 컨트롤을 하기 때문에, 컨트롤러 를 통해서 접근을 하여야 한다는 것이기 때문입니다.
Controller 에서 어떠한 view 를 호출하는지를 결정하게 됩니다. 보통 jsp 환경에서는 jsp 를 호출할 것이고, php 기반이라면 여기서 view 페이지를 호출하게 될 것입니다. 호출도 호출이지만, 결정 짓는다 라고 생각해보면 더 이해가 쉽습니다.
그리고 view 라는 것은 보통, jsp, php 등의 페이지에서 html 태그등을 포함하고 있는 영역을 말합니다. 보여지는 부분과 관련된 영역 이라고 보시면 됩니다.
좀 더 상세적으로 접근을 한다면, 보여지는 것에 대한 컨트롤 도 포함할 수도 있겠습니다.
보통은 템플릿 형태의 보여지는 영역을 View 라고 합니다.
그러면, 이제 모델 Model 이 남았습니다.
대체적으로 남아있는 소스들을 Model 이라고 생각하시면 됩니다. (헐...)
보통은 데이터 모델만을 Model 이라고 배우게 되면서, 혼란이 많이 생기게 되는데....
model 에 집착을 할 필요는 없다고 보여집니다.
중요한 것은, 과거의 View 와 Model 만의 형태에서. Controller 를 분리해내는 개념이기 때문입니다.
가장 중요한 개념은 Controller 인 것이죠.
훨씬 깊게 들어간다면, oop 의 interface 기능을 사용해서, view 와 model 의 연관성을 떨어뜨리는 동시에, 어댑터 패턴등을 활용 한 후에.
Controller 에서 View 와 Model 을 좀 더 컨트롤 해줘서,
View 에서는 Model 도 모르고, Controller 도 모르고.
Model 에서는 알림만 발송해주고.
Controller 에서는, 내가 어떤 모델 쓸까? 어떤 뷰를 쓸까? 이 정도를 정해 준 후에, 보안 관련 처리나 기타 등등을 포함하면서
구성되어가는 것이 MVC 패턴의 개념인 것으로 보여집니다..
그런데, 물론 웹에서 사용하는 방식에서는, Model 에서 변경알림을 해줄 방법이 없다보니까... Model 과 View 의 연관성이 조금 생겨버립니다. 그래서 이 부분을 좀 어찌해보려고 하면, javascript 를 활용하게 되는 거죠. html 요소를 appending 한다거나 하는 처리를 사용하게 됩니다.
이러면 계층이 좀 더 나뉘어지기는 하는데... 얼추 비슷한 개념이 되는 거죠.
너무 원칙적으로 접근하려고 하지는 말고, 계층을 나누는 개념 정도로만 접근을 해도 됩니다.
html 만 작성할 작업자를 위한 View 영역.
백엔드 작업자를 위한 Controller 영역.
백엔드 작업자와 DB 관리자의 연관적 작업을 위한 Model 영역. (비즈니스를 위한 영역도 Model 에 포함)
이렇게 세 분류로 나뉘어졌다 라고 생각하면 좀 더 쉽습니다.
백엔드 작업이 결국, Controller 와 Model 영역이 되는데.
웹에서는 호출의 구분점 등을 나누는 목적으로 Controller 를 쓰고, 공통적인 사항은 Model 에 넣을 수도 있겠습니다. (이게 개념에 좀 더 접근하는 듯 하네요)
영어니까요. 리모콘이 Remote Controller 니까, 우리가 만드는 Controller 는 일종의 리모콘 같은 느낌이 있을 것 같네요.
참고로 프레임워크에 따라서는, Model 영역이 데이터베이스의 Table 과 일치하게 하는 경우도 있기는 한데요. 그렇다고 해서, 데이터 통신 목적의 오브젝트(Table 의 컬럼형태) 만 Model 이라고는 볼 수는 없습니다. 정보라는 것이 DB 만의 것이 정보는 아니기 때문이죠. 웹으로 치면, 세션값도 정보이고. 로그인한 정보, 웹애플리케이션의 정보, 기타등등의 정보들도 다 정보니까요. (애초에 DB 안 쓰는 경우에는 Model 이 없다는 말이 되니까 앞뒤가 안 맞죠...) 그리고 정보가 아닌, 오브젝트들도 모델이라고 볼 수 있는 게 많습니다.
그래서, 그냥 컨트롤러 와 뷰를 제외한 것들은 모델 로 생각하는 게 훨씬 수월하다는 얘기인 거죠.
<모델에 대해서 더 파고 들어보자면?>
더 이상 알고 싶지 않으신 분은 이후부터는 읽지 않으셔도 됩니다. MVC 패턴은 Controller 와 View 만 알면 충분합니다. 나머지는 모델 로 인식을 하시는 것이 훨씬 수월합니다.
여기서는 Model 에 대해서 더 고민해보고자 적어봅니다.
1. Model 이 만약에 View 와 1:1 대응하는 ViewModel 형태라면 어떨까?
일단 쉽게 생각해서, ViewModel 이 너무 많아집니다. 로그인 정보라거나, 각각의 화면에서 동일하게 구성되는 데이터가. 매번 중첩이 되게 됩니다. 프로그램 형태에서는, 보다 엄격한 MVC 형태였다면. Model 에서 View 로 알림을 해줘야 하는데...
각각의 ViewModel 등이 일일이 알림(뷰를 Updates 하는 동작) 을 하려고 한다면....무리가....
=> 모델은 우리가 보통 클래스를 생성하듯이, 각각의 목적에 맞게 생성하면 될 것이라는 점을 추론 할 수 있다.
2. Model 이 만약에 DB 의 Table 과 일치한다면?
이것은 테이블의 설계가 단순하게 되어있을 때에는 가능할 수도 있겠습니다만.. 테이블 구조가 좀 더 복잡하고, 훨씬 효율적으로 사용하기 위한 구조로 되어 있다면. 어렵게 됩니다. option 값만을 생각해본다면, option_name, option_value 라는 두개의 컬럼만을 갖고 있는 구조의 테이블에, 옵션값들을 넣었다고 합시다. 어플리케이션에서는 이 옵션값들을 상당히 자주 불러오는 형태가 되었다고 한다면.
이 두개의 방식은 잘 맞지가 않습니다. 물론 option_name = 'timer' 이런 식으로 하나의 옵션값씩 불러올 수는 있지만.
결과적으로, 테이블의 형태와 모델의 형태가 다르다는 얘기입니다.
거기에 더해서, 테이블 설계의 변경시마다....모델을 변경할 수는 없는 일입니다. 뭔가 일을 더 만드는 수가 생길...
=> 하다보면, 결국 Model 은 테이블의 형태와 멀어져 갈 것을 예상 할 수 있다.
3. 어플리케이션의 중복되는 로직들은 어찌하나요?
컨트롤러에 넣어야 할까요? 모델에 넣어야 할까요?
저는 모델 이라고 생각합니다. 보안 소스나 공통적인 소스들을. 컨트롤러에 넣는다는 것이...조금 안 맞습니다.
이유인 즉슨, 아무것도 컨트롤 하고 있지 않기 때문입니다. '공통적인 처리를 한다' 라는 것과 '컨트롤을 한다' 라는 것은 다소 상반된 개념으로 볼 수가 있기 때문이죠.
그리고 OOP 의 특성상 어차피, 오브젝트로 구현될 것이기 때문에. 모델 에 포함시키는 것이 맞다고 생각합니다.
4. 결론
그래도, 보통은 웹어플리케이션에서는 Table 형태의 모델을 모델 이라고 지칭하는 경우가 많기는 하지만, 개념적으로 봤을 때에는 큰 분기점을 나누고 모델과 뷰를 컨트롤 하는 것이 '컨트롤러' 라고 생각하고. 하나의 방향성을 가지는 로직이나 데이터 들은 모델 이라고 생각해야 맞다고 봅니다.
목적 자체가 뷰를 컨트롤 하거나, 모델을 컨트롤 하는 것이 아니라면. 포함될 영역은 모델 이라고 보여지네요.
어떤 개념에서 보면, 컨트롤러 라는 것도 결국은. 화면에 보여질 영역을 컨트롤 한다는 개념으로 볼 수도 있겠네요. 보여질 영역을 컨트롤 해주고, 해당 되는 뷰를 선택해주는 것이죠. 웹에서는 이 개념을, request 를 컨트롤 해주는 개념으로 생각해도 되지 않을까 싶습니다.