MVC란 Model View Controller의 약자로 애플리케이션을 세가지의 역할로 구분한 개발 방법론입니다. 사용자가 Controller를 조작하면 Controller는 Model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 됩니다.
좀 더 자세하게 특징을 살펴보면,
모델은 순수 Application Data만을 가지고 있습니다.
유저라는 Application있다고 가정을 하면 이름, 나이, 주소, 전화번호, 아이디, 비밀번호 같은 정보가 모델에 저장되게 됩니다. 뷰는 유저가 컨트롤러를 통해 전달한 요청을 모델을 통해 전달받고 유저에게 보여주는 역할을 합니다.
뷰는 어떻게 모델의 데이터에 접근할 지에 대한 것만 알고 있고, 이 데이터 자체가 무엇을 의미하는지, user가 그것을 어떻게 조작하는지에 대해서는 알지 못합니다.
Controller는 view와 model 사이에서, view에 의해 작동된 이벤트를 그 이벤트에 대한 적절한 방식으로 응답을 합니다. 대부분의 경우 그 리액션은 model에 있는 함수에 의해 시작됩니다. 뷰와 모델은 그 이벤트에 대한 알람에 의해 연결되어있기 때문에 자동적으로 이 응답결과가 뷰에 반영됩니다.
이렇게 mvc패턴을 사용하면 서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 확장성 그리고 유연성이 증가하고, 중복 코딩이라는 문제점이 사라지게 됩니다.
View와 Model이 의존적인데에서 나올 수 있는 문제점들
MVC패턴의 단점은 기본기능 설계를 위해 클래스들이 많이 필요하기 때문에 복잡할 수 있습니다.
이것은 속도가 중요한 프로그램에서는 권장 되지 않을 수 있습니다. 또한 설계시간이 오래 걸리고 숙련된 개발자가 필요합니다. 가장 큰 문제점은 Model과 View의 의존성이 완벽히 분리 할 수 없기 때문에 패턴이 모호해질 수 있고 변형이 올 수 있습니다.
View와 Model이 서로 의존적이라는 점입니다.
최대한 서로의 의존성을 줄일수 있도록 노력해야 합니다.
그런 노력에 의해 파생되어 나온 프레임워크가 MVP 패턴 입니다.
MVP (Model + View + Presenter)
MVVM (Model+ View + View Model)
Model과 View의 완벽한 분리가 이루어질 수 있으면서 MVC의 장점을 갖고있는 MVP 혹은 MVVM이라는 패턴을 사용하면 됩니다.
MVVM패턴이란, 아키텍쳐에서 entity와 usecase를 포함한 model계층, repository혹은 presenter역할을 맡는 중간 계층인 infrastructure계층에 해당하는 view model, 가장 바깥의 ui를 담당하는 view 계층을 분리해 의존성 규칙에 따라 관심사를 분리한 형태의 디자인 패턴을 말합니다. 구성단위 각각의 역할은 다음과 같습니다.
Model에 의존성이 없는 View, View와 비즈니스 로직의 철저한 분리.
Model의 내용을 ViewModel이 갱신 및 가공해 View에 그 결과를 표시합니다.
View는 말 그대로 보여주는 작업과 유저 인터렉션을 받는 역할을 하며, ViewModel에게 유저 인터렉션에 따라 수행되어야 할 명령(Command)을 내립니다.
ViewModel은 Model을 가공해 View에 전달하거나, View에서 온 명령에 따른 작업을 수행해 그 작업이 끝나면 View를 이에 맞춰 바꿔줍니다.
여기서 바꿔주는 작업은 데이터바인딩 패턴, View가 ViewModel에게 명령을 내리는 패턴은 커맨트패턴을 사용해 구현되었습니다.
이 두가지 패턴으로 View Model과 View는 1:다 관계로 만들고, View와 Model 사이의 의존성을 없앱니다.
이렇게 의존성이 없어진다면 각각의 부분이 독립적이기때문에 모듈화 하여 개발할 수 있다는 점이 장점입니다. 하지만, 단점은 ViewModel의 설계가 쉽지않고 데이터 바인딩기법을 통해 View를 바꿀 때 많은 코드의 작성을 필요로 하므로 간단한 View나 로직을 만들 때에도 하는 일에 비해 많은 코드의 작성을 해야한다는 것이 단점입니다.