개발자
MVC vs MVVM
어제부터 MVVM 아키텍처에 대해 공부를 시작했는데 이전에는 MVC 아키텍처를 사용해왔습니다. MVC의 단점은 프로젝트가 커질수록 Controller가 비대해지는 경향이 있다는 점입니다. 그래서 Controller의 부담을 줄이기 위해 ViewModel을 도입한 MVVM이 탄생한 것으로 알고 있습니다. 하지만 MVVM을 공부하면서 느낀 점은 View와 ViewModel 사이의 상호작용이 많아지면서 컴포넌트가 많아질수록 코드가 길어지고 복잡해진다는 것이었습니다. 그래서 MVC처럼 다시 View와 Controller를 분리하여 MVC와 MVVM을 혼용하여 작성하면 좋을 것 같다는 생각이 들었습니다. 이에 대해 구글링을 해봤지만 관련 글을 찾기 어려웠습니다. 이렇게 개발했을 때 발생할 수 있는 문제점은 무엇이 있을까요?
답변 2
사실 이미 그런 생각을 하고 개발을 하셨던 분들이 있습니다! 말씀하신 패턴과 정확하게 일치하는지는 모르겠는데, 보통 MVVMC로 표현하시는 분들이 있었던거 같은데, 요새도 그렇게 하시는 분들이 있는지는 모르겠네요. 사실 저는 현업에서 적용해본 적은 없습니다. MVVM으로만 작성을 해도 하나의 로직을 구현하기 위해서 굉장히 많은 코드를 작성해야하는데, 그 사이에 Controller까지 껴버리니까 fetch 한번 하는데도 수많은 코드를 작성해야하고, 또 너무 난잡하게 나눠지다보면 가독성이 떨어지는 문제가 발생하거든요. 뭐 하나 확인하려면 코드 점프하고 점프하고 점프하고... 일단 https://skimp-blog.blogspot.com/2012/02/mvvm-is-dead-long-live-mvvmc.html 이걸 한번 참조해보시면 좋을 것 같아요!
익명
작성자
2024년 05월 22일
오 MVVM-C(oordinator)만 있는줄 알았는데 MVVMC가 있었군요! 답변 감사합니다:)
프로그래밍에서 중요하게 생각하는 원칙들이 있습니다. 물론 이 원칙들도 장단점이 있기에 적재적소에 사용하는 것이 중요하지만 지금 글쓴이 분의 상황에선 디자인 패턴보다도 원칙들을 공부해보는 것을 추천합니다! 예를 들어 SOLID, DRY 같은 것들이요!👍👍👍
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 05월 20일
MVC와 MVVM을 혼용하여 사용하는 것은 일반적으로 추천되지 않습니다. 각 아키텍처 패턴이 고유의 목적과 구조를 가지고 있기 때문인데요, 두 패턴을 섞어서 사용하게 되면 아래로 인해 코드 유지보수가 어려워질 수 있습니다: 1. **코드 이해 및 유지보수하기 어려움:** MVC와 MVVM은 각각 모델(Model), 뷰(View), 컨트롤러(Controller) 그리고 뷰모델(ViewModel) 사이의 상호작용 방식이 다릅니다. 따라서, 두 패턴을 혼용하면 프로젝트 전체에서 일관된 코드 스타일 및 구조를 유지하는 것이 어렵습니다. 2. **상호작용 복잡성 증가:** ViewModel은 View의 State를 관리하는 역할을 합니다. 반면에 Controller는 Model과 View 사이의 중간자 역할입니다. 이 두 역할을 혼합시키게 되면 ViewModel 이나 Controller의 복잡성이 증가하게 됩니다. 3. **응집도 하락:** 각 패턴은 구조화된 역할 분배와 관심사 분리를 통해 코드 응집도를 높입니다. 하지만, MVC와 MVVM을 혼용하면 공통 관심사가 넘나들게 되며 응집도가 하락할 수 있습니다. 모든 아키텍처 패턴에는 각각의 장단점이 있으며, 어떤 프로젝트에 적합한지는 프로젝트의 규모, 복잡성, 요구사항 등 여러 요소를 고려해야 합니다. MVVM이 더 복잡하다고 느껴진다면, 상황에 맞게 MVC를 계속 사용하는 것도 좋은 선택일 수 있습니다. 아니면 다른 아키텍쳐 패턴(VIPER, Clean Architecture 등)을 고려해볼 수도 있습니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!