MVC 모델 구성 & 특징.
- Model, View, Controller로 이루어져 있다.
- 비즈니스 로직과 UI로직을 분리한다.
- 이러한 분리를 통하여, 유지보수를 독립적으로 수행할 수 있는 장점이 있다.
- 프로그램의 확장성과 유연성을 높인다.
Model
- 프로그램에 사용되는 데이터를 의미.
- model 내에는 view, controller에 대한 정보가 전혀 없다.
- model은 정보를 반환하거나 설정하는 것.
- model을 잘 설계하는 것 ? == 해당하는 domain을 얼만큼 이해하는지에 대한 척도.
View
- 사용자에게 보여지는 부분 == user interface
- view에서 별도의 데이터를 보관하지 않는다.
- view에서 사용할 데이터는 model을 통하여 사용된다.
- domain 로직의 어떠한 것 알고 있지 못하다.
- 객체만 전달받아서 상태를 출력하는 역할만을 담당해야한다.
- 그렇기 때문에, 따로 저장하고 관리하는 클래스 변수, 인스턴스 변수가 있을 필요가 없다.
Controller
- model - view 를 이어주는 다리 역할
- 입력이 발생했을 때, 이에 대한 통지를 담당한다.
- controller는 view와 model이 각각 어떤 역할과 책임이 있는지 알고 있어야 한다.
단점
- 한 기능에 대하여 클래스가 많이 생성될 수 있기 때문에 복잡하다.
- 설계시간이 오래 걸리고, 숙련된 개발자가 필요하다.
- model과 view의 완벽한 분리가 어렵다.
- 따라서, model - view의 의존성이 존재할 수도 있기 때문에 패턴이 모호해지고, 변형이 올 수 있다.
내것으로 만들기
쓸모없는 경험은 없다.
MVC패턴을 깊게 이해하면서, 작년 말에 진행했던 우테코가 떠올랐다. 비록 프리코스에서 떨어졌지만, 이때 진행한 작업들이 현재의 나에게 큰 교훈을 준다. 프리코스에서는 무조건 맞춰야만하는 법칙같은 것들이 존재했는데, 그게 바로 MVC 모델이었다. 이 과정을 다시 되새겨보니, MVC 모델이 가지는 장점과 단점을 모두 느낄 수 있었고, 내가 얼마나 부족한 프로그래밍 실력을 갖고 있었는지도 볼 수 있었다. 그때 프로그램의 완성도를 생각하니 매우매우 부끄럽다.
내가 느낄 수 있었던 MVC 모델의 장점은 완벽하게 분할이 되었을 때, 정말 유지보수하는 것이 편하고, 어느 부분이 잘못된 것인지를 확인하기가 편리했다는 것이다.
하지만, 단점에서도 나타나듯이 적정수준의 MVC 패턴 이해가 필요하고, 이 이해를 바탕으로 "잘" 설계해야한다. 여기서 나는 꽤나 힘들었었다. 설계를 완벽하게 끝냈다고 생각하고 코딩을 하며 구체화를 시키는 도중에도 MVC가 꼬여버렸다. 이러한 문제를 그 당시에는 해결하지 못하여 Model과 Controller, View가 엉켜있는 상태로 제출한 기억이 있다. 이번 공부를 통하여, 완성도 높은 MVC 패턴이 어떠한 이점을 가지는지 생각해볼 수 있었고, 내가 겪은 문제들을 단점에 대입하여보니 정말 이해가 잘됐다.
사족
프로그래밍 공부는 엄청나게 복선이 많은 영화같다고 생각한다. 이걸 어디다 써먹는지 모르는 것을 배우고 적용시키다보면, 시간이 흐르고 내가 필요한 프로젝트나 공부를 진행할 때 '아, 그때 이거 공부했었는데 이게 이렇게 이어지는구나!'라는 경험이 꽤 많았다. 이러한 경험들이 쌓이고 쌓여서 나중에 나올 것들도 이해하기 쉬울거라고 생각한다. 또한, 그 복선을 발견하는 상황에서 프로그래밍이 재밌다는 생각을 한다.
