시작하기 앞서...🤔
지난 1년 동안 개발을 공부하면서 여러 프레임워크를 배웠다. Django나 Android같은 것 말이다. 물론 Spring은 지금 현재 공부하려고 하고 있고 여튼 그런 것을 배우면서 여러 디자인 패턴에 대해서 알게되었다. MVC, MVP, MVVM이다. 단순히 약어와 뜻만 알고 있고 왜 쓰는지 생각을 해본적은 없는거 같다. 그래서 오늘은 왜 이러한 디자인 패턴을 쓰는지 알아보자.
🤔 MVC는 무엇인가?
Model View Controller의 약어로 Data를 Control 하여 View뷰여준다.
위와 같이 알고 있다. 내 경험 상 Django Framework를 배울 때 가장 많이 들었던 단어 중 하나이기 때문에 그때 당시 배웠던 내용을 상기하자면 다음과 같다.
📦 model
Django 내부에서는 Model.py에서 Sqlite3를 이용한 DB를 바로 만들 수 있다. 이때 파이썬 코드를 활용하여 만든다. 이걸 Model을 만든다고 들었고 배웠다. 물론 내가 틀렸을 수도 있다. 이러한 Model이라는 것은 상당히 여러 개의 의미를 뜻하는 단어이기에 확실한 정의가 필요하다. 그렇다면 나는 이 모델이라는 것이 무엇을 뜻하지는 이해하고 있는가?
사실 데이터를 저장하는 장소 그 자체 이하, 이상으로 생각하고 있지 않다. 사용자에게 보여줄 데이터를 보관하고 있는 곳. 나는 그것을 Model로 생각한다.
🏞 View
Django에서는 View가 아닌 Template로 정의한다. 물론 둘 다 같은 의미를 갖고 있다. Template에서는 사용자에게 보여줄 View를 만들었다. 즉, DB에 있는 데이터를 꺼내와서 Template에 rendering하는 과정이 바로 View라고 인지하고 있다. 이때 Javasript를 사용할 수도 있고 HTML, CSS 둘 모두 이용하여 View를 구성하게 된다. 그리고 Django 내부의 Template에 적용하기 위한 문법도 따로 존재하긴 하지만, 그 문법이 어려운 편은 아니다.
🕹 Controller
Django에서는 View라고 이야기한다. 그때 당시에는 왜 이게 View지? 라고 했는데, 웃긴건 왜 지금도 이게 View지? 라고 생각한다. Django에서 View는 일반적인 MVC 프레임워크의 Controller이다. 즉, Model과 View를 통제할 수 있는 부분을 이야기한다. 데이터가 있으면 그 데이터에 필요한 부분을 조작하는 역할을 담당한다. Django에서는 view.py에서 해당 코드를 함수의 형태로 작성할 수 있다.
그럼 다시 내 자신에 물어보고 싶다. 그래서 MVC가 무엇이야?
웹 사이트를 만들 때 보다 간편히 통제하고 제어하기 위해 만들어진 가장 간단한 웹 구축 디자인패턴
음... 뭔가 더 자세히 진 것 같다.
그러면 MVC에서 각각 하는 역할을 보면 View는 Model에 관여하지 않는다. 그러면 누가 model에 관여하는가? 당연히 Controller이다. Controller가 Model에 있는 데이터를 빼서 View에 넣어준다. 사용자가 요청을 View가 받아서 Controller로 통제하고 이를 Model에 넣어준다. 이때 model의 경우 View에 필요한 데이터를 바로 보내줄 수도 있다.
웹이 구동하기 위한 각자의 기능을 나눈 뒤에 이를 통해 웹 사이트를 보다 빠르고 쉽게 만드는 것
이때 받은 느낌은 각자의 역할에 아주 충실한 애들이라는 것이다. 이부분이 바로 디자인 패턴을 사용하는 이유로 생각한다.
물론 가장 단순한 패턴이라는 장점도 존재하지만
사이즈가 커지면 view와 model의 관계성도 높아진다. 의존성이라는 이야기가 더 알맞는 것 같다. 아니 View는 model에 관여 안한다면서요?
그렇다 관여 안한다. 단지 model에서 곧바로 view로 보내지는 데이터가 많아질수록 해당 부분을 케어하기 위한 과정이 복잡해질 수 있다는 것이다. 즉, 데이터를 완벽하게 통제하기 위해서는 controller도 봐야되고 model도 View도 봐야된다.
그럼 그런 사이즈가 커지면 당연히 유지보수하기가 복잡해진다. 이러한 단점이 존재하면 어떤가? MVC의 한계점으로 볼 수 있지 않을까?
그다음은 MVP이다.
🤔 MVP는 무엇인가?
MVC와 크게 다르지 않으며 Control이 presenter로 바뀐 것 뿐이다.
사실 MVP는 약간 생소하다. 왜 이걸 만들었을까?
기존의 MVC의 한계점은 무엇인가? 그건 아마 model에서 곧바로 View가는 데이터를 통제하기 위함이 아닌가 생각든다. 중개자를 오로지 presenter로 지정하여 model과 View를 통제하기 위함이 아닌가?
📣 presenter
사실 presenter를 한국어로 직역하면 증여자라는 의미이다. 건네준다는 것이다. 무엇을? View와 Model에게 데이터를 건네준다는 것이다. presenter와 View는 서로 직접적으로 관여하지 않는다. 오로지 중개자인 presenter를 통해서만 서로에게 간접적인 영향을 미칠뿐이다.
즉 MVC와 다르게 오로지 Presenter에서만 데이터를 통제하기 때문에 presenter만 보면 된다. 뭔가 더 단순해졌다. 기존의 MVC 패턴의 한계점을 보완한 느낌이 난다.
웃긴건 MVC의 한계점을 극복했는데 MVC에서는 없었던 새로운 한계점이 생겼다. 아까 이야기 했듯이 Presenter에서만 데이터를 통제한다고 했다. 그래서인지 View와 presenter의 의존성이 높아졌다. View의 통제가 유연해지지 않았다는 단점이 생긴 것이다.
🤔 MVVM은 무엇인가?
Model View ViewModel의 약자로 뭔가 더 이상하게 바뀌었다.
사실 MVVM은 안드로이드 개발에 처음 참여할 때 처음 들어봤다. 잘 알고 있지 않으나, 그 때 ViewModel을 사용했었던 것으로 알고 있다.
𝌭 ViewModel
ViewModel은 View를 표현주기 위해 나타난 Model이다. 물론 수정 사항이 생기면 model에 이를 전달하기도 한다. 이러한 ViewModel은 MVP나 MVC의 한계점이었던 View와 Presenter의 의존성이 너무 강했거나 model과 View의 의존성이 너무 강했던 한계점을 완화해주는 디자인 패턴이다. 물론 단점으로는 구현하기 너무 어렵다는 것이다. 구현하는 걸 보기만 했지... 해보진 않았다...ㅠ 빨리 해야겠다!
♉️ 결론
그럼 결국 디자인 패턴을 왜 쓰는가?
내 답변: 보다 빠르고 간편하게 개발하기 위해서 쓰는 것이다.
복잡하게 생각하는 건 질색이다. 단순하게 가자.
하지만, 각각의 디자인 패턴들이 왜 탄생했는지 그 의미가 무엇인지 알고 있다면, 그리고 각각의 다자인 패턴의 장점과 단점을 알고있다면, 오늘 학습한 내용은 너무나도 의미가 있는 것 같다.
다지인 패턴에서
디자인은 웹을 구동시키기 위한 아키텍처를 디자인 한 것.
패턴은 해당 디자인을 통해 각각의 기능과 역할을 부여한 것.
즉,디자인 패턴은 웹을 구동시키기 위한 아키텍처에 각각의 의미와 기능, 역할을 부여하여 보다 빠르고 간편하게 개발할 수 있도록 패턴화 시킨 것이다.
