※지극히 저의 언어로 해석해서 이해한 내용입니다.※
그게 뭔가요?
Architecture 패턴이란 개발 규칙 같은 것 입니다. 아무생각 없이 코딩을 하다보면, 반복되는 코드, 꼬이는 로직, 아무렇게나 지은 변수명을 발견하실 수 있습니다. 이것을 협업을 위해 남들이 본다면 어떨까요? 알아볼기 힘들기 때문에 개발 규칙을 정해야 되고, 그 규칙에 서로 적응해야 되기 때문에 협업 능률이 낮아질 것입니다.
이런 상황을 대비해 나온것이 Architecture 패턴입니다. Architecture 패턴을 사용하면 코드의 품질을 향상시킬 수 있습니다!(같은 역할을 하는 애들을 묶어서, 잘 재사용할 수 있도록 만드는 것을 의미)
종류
Architecture 패턴의 종류로는 mvc, mvp, mvvm, mvi가 있습니다. 뒤로 갈수록 구현은 어려워지지만 성능? 차원에서는 이점을 얻을 수 있습니다.
mvc
*참고용 사진입니다. 내용과 다른점이 있습니다.
가장 보편적인 아키텍처 패턴입니다. Model, View, Controller로 구성되어있습니다. 각각의 역할은
Model
1.데이터를 가지며 애플리케이션에서 사용되는 데이터와 그 데이터를 처리합니다.
2.View 또는 Control에 묶이지 않아 재사용 가능합니다.
View
1.사용자에게 보일 화면을 표현(xml화면).
2.앱 및 UI와의 상호작용에서 컨트롤러와 통신합니다.
3.유저가 어떤 입력(Action)을 하든 View는 무엇을 해야 할지 모릅니다.
Controller
1.사용자로부터 입력을 받고 이 입력을 모델에 의해 View 정의합니다(Activity/Fragment 파일).
2.모델의 데이터 변화에 따라 뷰를 선택합니다.
mvc 장점
model과 view가 분리되어있습니다(유지/보수가 간편해짐).
model이 비종속적이어서 재사용이 가능합니다.
가장 구현이 쉽고 단순합니다.
mvc 단점
model과 view사이에 의존성이 발생합니다(앱이 커질수록 model도 복잡해지면서, 유지/보수가 힘듦).
UI에 변경이 있을때마다, controller에 코드 변경또한 불가피 합니다.
MVP
*참고용 사진입니다. 내용과 다른점이 있습니다.
특징은 Activity가 View의 역할만 한다는 것입니다.
Android에 있어서 MVP는 컴포넌트 분리가 좀더 명확하게 이루어졌다고 할 수 있습니다.
Model
(mvc때와 같습니다.)
1. 데이터를 가지며 애플리케이션에서 사용되는 데이터와 그 데이터를 처리합니다.
2. View 또는 Presenter 등 다른 어떤 요소에도 의존적이지 않아 재사용이 가능 합니다.
View
- 여전히 화면에 역할을 합니다.
- Activity를 자연스럽게 View의 일부로 간주하게 되었습니다.
Presenter
- Model과 View사이의 매개체을 합니다.
- Controller와 유사하지만, View에 직접 연결되는 대신 인터페이스를 통해 상호작용 한다는 점이 다릅니다.
- 인터페이스를 통해 상호작용 하므로 MVC가 가진 테스트 문제와 함께 모듈화/유연성 문제 역시 해결할 수 있습니다.(UnitTest가 가능함)
- 뷰에게 표시할 내용(Data)만 전달하며, 어떻게 보여줄지는 View가 담당합니다.
mvp 장점
- 코드가 깔끔 해집니다.
- Model과 View 간의 결합도를 낮아지며, 새로운기능 추가 및 변경을 해야 할 때, 관련된 해당 부분만 코드 수정하면 되기 때문에 확장성이 좋아졌습니다.
- 더불어 유닛 테스트시, 테스트 코드를 작성하기 편리해지기 때문에 더 쉽고 안전한 코딩이 가능해집니다.
mvp 단점
1.애플리케이션이 커질수록 View와 Presenter 사이의 의존성이 강해집니다.
2.기능이 많아지면 Presenter의 비중이 커지기 때문에 분리하기가 어렵습니다(Presenter와 View가 1:1 관계를 갖고 있기 때문입니다).
MVVM
*참고용 사진입니다. 내용과 다른점이 있습니다.
이전까지에 Architecture 패턴들은 view가 다른 구성요소와 의존성이 생기는 문제와 Activity에 비례해 같이 늘어나는 Presenter가 있었습니다.
mvvm은 이것을 해결하기 위해 Observer pattern을 사용합니다.이를 활용해 객체의 변경이 일어날 때마다 UI를 갱신하도록 만들었습니다.
Observer pattern이란 대상을 감시하고 있다가, 변경해야되는 상황이 왔을 때 대상에게 알려서 바꾸는 기법이라고 생각하면 좋습니다.Model
(mvc때와 같습니다.)
1. 데이터를 가지며 애플리케이션에서 사용되는 데이터와 그 데이터를 처리합니다.
2. View 또는 Presenter 등 다른 어떤 요소에도 의존적이지 않아 재사용이 가능 합니다.
View
- ViewModel을 Observe하다가 값이 변경되면 해당 값을 이용하여 랜더링합니다.
- Command나 databinding을 통해 의존성 완화합니다.
ViewModel
1.Model과 상호 작용하며, View에 종속되지 않고 1:N 구조를 갖습니다.
2.MVVM은 View가 어떤 종속성도 가지지 않기 때문에 재사용이 가능합니다.
mvvm 장점
- View와 Model이 독립되어 있습니다.
- 바인딩하기 때문에 코드의 양이 감소합니다.
- ViewModel에서 View 코드가 없기 때문에 UnitTest를 쉽게 할 수 있습니다.
mvvm 단점
- 데이터 바인딩이 필수적으로 요구됩니다.
- 간단한 UI에도 ViewModel을 설계해야 하고, 그만큼 과도한 엔지니어링이 일어날 수 있습니다.(구현이 어렵다는 말)
총평
미숙하지만 정리에 필요성을 느껴 글을 써보게 되었습니다.
각각에 장점이 있으니 상황에 맞게 잘 사용하시면 좋을것 같습니다.
다른 좋은 글들도 많으니 꼭 읽어보세요!!
출처
