MVVM에 대해서

MVVM

• 프레젠테이션 로직(이하 ‘프’)과 비즈니스 로직(이하 ‘비’)을 분리하기 위한 대표적인 패턴 중 하나.
• 프와 비는 매우 긴밀하게 상호작용 하기 때문에 ‘인위적인’ 혹은 ‘의도한’ 분리가 없다면 수많은 요소와 관계들이 복잡하게 얽혀 리소스의 해독이 난해함. 이로 인해 애플리케이션의 확장과 유지보수의 난이도를 높이는 요인이 됨
• MVVM은 Model, View Model, View로 구성되는데, Model은 로컬 혹은 원격지로부터 데이터를 가져와 정제 혹은 가공하여 View에서 보여줄 데이터를 생성함.
• View Model은 Model에서 생성된 데이터를 View에 바인딩함. 이로 인해 View는 Model과의 의존성이 완전히 사라지게 되는데, MVVM 패턴의 이러한 특징은 MVC 패턴과 대비되는 가장 큰 특징 중에 하나. MVC에서 C에 해당하는 Controller의 역할은 Model과 View를 바인딩시키는 것이므로, Model과 View는 비록 이 패턴을 사용하지 않았을 때 보다는 의존성은 낮다 하여도 여전히 Model과 View 간 의존성이 남아 있으므로 애플리케이션이 비대해질수록 복잡도가 높아짐.
• View는 사용자들에게 보여지는 영역으로 프레젠테이션 로직이나 리소스들로 구성됨.
• 이러한 프와 비를 구분하는 디자인 패턴들은 유용하지만 실무에서 적용할 때는 주의할 점이 있음
• 이를테면, 프레임워크를 통해 구현된 데이터 바인딩은 효과적이긴 하지만 이것 자체를 이해하기 위한 학습의 난이도가 상당히 높은 편임. 바인딩이 기능은 막강한데 반해 너무도 심플한 탓에 빠르게 이해하기에는 직관적이지가 않음.
• 그리고 데이터 바인딩 수정된 데이터를 '자동'으로 View에 반영하는 것이다 보니 어느 정도의 딜레이가 예정되어 있으며 이로 인한 성능 저하는 필연적으로 발생함. 요즘은 워낙에 컴퓨팅 성능이 좋아져서 이런 부분은 단점으로 부각되지 않고, 무엇보다도 애플리케이션의 특정 리젼(region)에서 데이터 업데이트를 위한 비즈니스 로직과 구성이 복잡하다면 소스코드가 난해해지는데, 이런 부분에 바인딩을 적용되면 소스코드를 간결하게 작성할 수 있다는 장점이 있음. 언급한 바인딩의 단점 보다 이 장점이 훨씬 위력적인 효과를 발휘하므로, 이런 경우에는 적극적으로 바인딩을 도입할 것이 권장됨
• MVVM은 명시적인 구조가 권장되다보니 각 구성 요소의 입력과 출력 데이터에 대한 설계가 정교하게 이루어져야 됨. 그렇지 않다면 MVVM의 각 구성 요소의 역할이 모호해져 소스코드가 난해해짐. 이러한 현상은 비단 패턴을 사용하지 않을 때도 발생하므로 단점이라 생각되지 않을 수도 있지만, 우리들은 우리가 가진 문제점을 완벽하게 해결해 줄 것이라는 미신을 갖고 이것을 사용하게 됨. 성능과 효과가 뛰어나다고 입증된 도구에 대해선 그 미신은 더욱더 커지는 경향이 있음. 따라서 도구에 대한 맹목적인 믿음을 갖지 말고 자기가 작성한 것들을 깔끔하게 정리하는 습관을 만들고 실천해 나가는 것이 무엇보다 중요함