MVC 패턴과 MVT 패턴
Django에서의 MVT패턴은
일반적인 MVC(Model View Controller)패턴과
각각의 패턴이 하는 일은 크게 차이가 없다.
일반적인 MVC(Model, View, Controller)의
상호 작용에 대해서는 아래에 설명과 같다.
데이터베이스와 상호 작용하는 인터페이스 역할을 한다.
얽매이지 않고 데이터와 상호작용 할 수 있다.
・View : 웹 응용 프로그램인 브라우저에서
[1]프레젠테이션 로직을
처리하여
UI로 나타낸다.
・Controller : View에서 핸들러의 흐름을 처리하거나
Model의 데이터를 업데이트 처리하는 로직을 제공한다.
파악하고 처리해 View로 전달된 내용을 파악한 후에
View를 통해 사용자로부터 데이터를 얻는다.
또한 Model을 통해
View를 변경하거나, 데이터를 업데이트 하여
지정된 로직을 구현한다.
일반적인 웹 프레임 워크(FrameWork)에서는
이를 MVC(Model View Controller) 패턴이라 말한다.
하지만 Django에서는 이를 조금 변형해
MVT(Model View Template)패턴이라 말한다.
아마 개인적으로는 Java의 MVC패턴에서 나오는
단점들을 개선한 것이 MVT패턴이 아닐까하는 생각을
개인적으로 하고 있다.
위의 그림은 MVC 패턴과 MVT 패턴을 비교한 그림이다.
결론부터 말하면 기본 틀 자체는
MVC(Model View Controller)패턴과
MVT(Model View Template)패턴은
이름만 다를 뿐 사실상 동일하며
아래와 같이 결론 내릴 수도 있다.
Model(MVC) = Model(MVT)
View(MVC) = Templates(MVT)
Controller(MVC) = View(MVT)
따라서 MVC패턴과 MVT패턴은 사
실상 이름만 다를 뿐이지 같은 개념이다.
물론 세부적으로 하는 일은 조금 다르다.
Django에서의 MVT패턴은 아래와 같다.
・Model : MVC 패턴의 Model과 마찬가지로
・View : 프레임 워크에서 실제 브라우저에 보이는
・Template : MVC 패턴에서 Controller와
따라서
View에서 모든
[2]비즈니스 로직을
처리한다.
또한 Model과 Templates간의 다리 역할을 하기도 한다.
Django에서의 MVT패턴은
일반적인 MVC(Model View Controller)패턴과
각각의 패턴이 하는 일은 크게 차이가 없다.
따라서 MVC 패턴과 MVT 패턴은
넓게 보면 동일하다고 할 수 있다.
하지만, MVT패턴에서는 View에
프레젠테이션 로직이 아닌,
비즈니스 로직을 포함시켜야 한다고 주장하는 패턴이다.
또한 기존 MVC에서 Controller에서 처리해야 했던
일부를 Django 프레임 워크에서 자동적으로 처리 한다.
즉, MVT 패턴은 MVC 패턴의 입장에서 보면
Model-Template-View + Controller의 형태로
구성되어 있다고 봐도 과언이 아니다.
다만, Controller의 역할의 일부를
Django에서 처리하기 때문에 종종 생략되는 경우가 있다.
위의 내용으로부터 알 수 있는건
MVC패턴과 MVT패턴의 패턴 자체만 놓고 보면
차이점이 없다는 것이다.
하지만 차이점은 당연히 있을 것이다.
MVC 패턴의 어떤 문제점을 개선하기 위해
MVT 패턴을 만들었을 것이기 때문이다.
MVC 패턴과 MVT 패턴의
차이점을 알기 위해서는 패턴 자체가 아니라
이 두 가지 패턴이
어떤 상호 작용을 하고 있는지에 대해 주목해야 한다.
그럼 차이점을 설명하기 전에
각 패턴의 아키텍처의 상호 작용을 살펴보자.
먼저 MVC 아키텍쳐를 살펴보자.
위에서 언급했듯이
실제 상호 작용자(Browser)와
Model, Controller, View가 서로 어떻게
상호 작용 하고 있는지에 주목해야 한다.
MCV에서는 실제 Browser와
상호 작용 하는 곳은 Controller이다.
Controlloer는 사용자(User)로 부터
요청(Request) 했을 때 같이 받았던
데이터들을 Model과 View에 각각 전달해 준다.
만약, 사용자가 실제 상호 작용자인 Browser를 통해
POST나 GET같은 요청(Request)에 따라
Model은 View로 부터 받은 요청에 따라 데이터를 처리 한다.
처리된 결과는 Model에서 Controller로 전달되며
Controller에서 Browser로 응답(Response)을 보내주게 되어
사용자(User)에서 UI로 표시 된다.
이 과정이 MVC 아키텍쳐(architecture)이다.
물론 위의 사진은 MVC 아키텍쳐들 중 하나이다.
Controller, Model, View간의 상호 작용의 관계는
각 프레임 워크가 추구하는 철학에 따라 다를 수도 있다.
다음으로 MVT 패턴의 아키텍쳐를 살펴보자.
여기서도 마찬가지로
실제 브라우저(Browser) 또는 사용자(User)가
서로 어떻게 상호작용 하고 있는지에 주목해 보자.
MVC 패턴과 비교해보면
MVT패턴에서 실제 User(MVC에서는 Browser)가
프레임 워크인 Django와 상호작용하고 있음을 볼 수 있다.
위에서 언급했듯이 아래와 같이
MVC와 MCT에서 각 요소들이 하는일은 큰 차이는 없다.
Model(MVC) = Model(MVT)
View(MVC) = Templates(MVT)
Controller(MVC) = View(MVT)
또 하나 재미있는 점은 MVC에서
브라우저와 상호 작용하는 Controller 역할을
MVT에서는 View가 일부 하기 때문에
View가 브라우저 또는 User와 상호 작용할 법한데,
사실은 중간에 Django 프레임 워크가 상호 작용한다는 점
그리고 실제 View는 URL과 상호 작용한다는 점이다.
그리고 이 URL이 중간 역할자인 Django와 상호 작용한다.
그렇다면 MVC 패턴과 MVT 패턴 중
어느것을 선택해야 할까?
지금까지 MVC 패턴과 MVT 패턴에 대해 살펴봤다.
MVT 패턴에서 나타나는 Django 개발자들의 철학은
일부 Controller의 역할을 시스템에 맞기는 것이
좀 더 좋다라고 나에게 이야기하는 것 처럼 들린다.
그리고 이러한 철학으로 부터
Django 프레임워크가 다른 프레임 워크에 비해
강력한 점으로 나타나는 듯 하다.
MVT패턴의 그리고
이를 사용하는 Django 프레임 워크의 강력한 점은
View와 URL만 지정해주면,
Django에서 그 이후는 알아서 해주기 때문에
개발자가 신경써야 하는 부분은 물론이고,
거기서 발생할 수 있는 에러까지 차단해준다.
이로 인해 개발자들은 좀 더 백 엔드나,
프론트 엔드
그러니깐 비지니스 로직과 프레젠테이션 로직에
좀 더 투자할 수 있을 것이다.
물론 이런 시스템에
Controller의 일부 역할을 맞긴다는 것에
조금은 거부감을 느낄 수 있다.
하지만,
현재 세계의 웹 개발의 흐름을 보면
현재 MVT 패턴과 같이
일부 역할을 시스템에 맞기는 것이,
그리고 그렇게 하는 것이 옳다는 것이
지배적이기 때문에 이를 부정하기 힘들다.
그리고 이를 증명하듯이
Python + Django를 사용해 애플리케이션을 구축하는
이름 있는 회사가 꽤 나 많이 보인다.
과거에 무차별적으로 개발할 때에
나오는 문제점들 때문에
MVC 패턴을 사용해 개발 패턴을 정립했듯이
MVC 패턴을 개발할 때에
나오는 문제점들 때문에
MVT 패턴과 같이 일부를 시스템에 맡기는
패턴들을 사용해 개발 패턴이 다시 한번 정립되었다고
나는 보고 있다.
웹 개발 패러다임이 한번 더 변한 것이다.
물론 그렇다 하더라도
MVC 패턴이 무조건 좋지 않다고 말할 수는 없다.
Controller의 모든 기능을 제어해야 한다면
기존 MVC 패턴을 이용하는 것이 옳을 것이다.
하지만 분명한 것은
웹 개발에 있어서
굳이 개발자가 지정하지 않아도 되는 부분을
지정하게 하여 나올 수 있는 리스크,
또한 로그인 기능과
그에 따른 DB 모델링과 같이
반복해서 같은 것을 개발 해야하는 부분이
계속해서 늘어나고 있다는 것,
그리고 이로 인해
생산성이 떨어지고 있으며,
이로 인한 비용이 증가하고 있다는 사실은
웹 개발자라면 느끼고 있는 사실 일 것이다.
따라서 생산성 향상을 위해서,
그리고 비용 절감을 위해서는
대부분의 경우는 MVT 패턴과 같은
아키텍처를 사용하는 것이 좋을 것이다.
소프트웨어 개발에서 말하는 프레젠테이션 로직은
비지니스 객체가 소프트웨어 사용자에게 표시되는 방법을
나타내는 로직을 말한다.
즉, 비지니스 모델이 실제 브라우저에서 나타나는
UI를 표시되는 로직을 말한다.
자세한 사항은 아래의 포스팅을 참고하길 바란다.
[2] 비지니스 로직 :소프트웨어 개발에서 말하는 비지니스 로직는
데이터 생성, 저장 및 변경 방법을 결정하는 비지니스 규칙을
인코딩하는 프로그램의 일부를 말한다.
자세한 사항은 아래의 포스팅을 참고하길 바란다.
