#"디자인 패턴"이란? 일단 이름 간지 합격 ㅋ
MVC 패턴이란 ? => Model + View + Controller의 약자로 , 안드로이드에서만 쓰이는 것이 아님. 하지만 나는 안드로이드에서만 쓸꺼지 ㅋ
위의 사진을 보면은 , User가 Controller를 통해서 입력을 하면 , Controller는 Model에 Data를 "저장 / 수정 / 삭제"등의 처리를 요청하고 , 요청한 Data를 불러와서 , View에 전달하게 된다. View는 전달 받은 Data를 User에게 보여주는 과정을 화살표를 통해서 보여주고 있다.
MVC에서는 Activity || Fragment가 View의 역할과 Controller의 역할을 한다.
MVC 패턴의 Model은 Data를 가지며 , Data를 처리 및 관리하는 역할을 한다. 또한 Controller || View에 종속적이지 않아서 재사용이 가능하다.
MVC 패턴의 View는 User에게 보여질 화면을 표현하는 영역이다. Controller가 전달한 Data를 오직 보여주기만 하는게 아주 중요함. User가 무슨 짓을 해도 View는 아무것도 모름. 그냥 Data를 User에게 보여주는 원툴. 그러나 파란박스에 묶여있는 것처럼 일부 책임이 존재 할 수 있어.
MVC 패턴의 Controller는 User로부터 입력을 받고 , 이 입력을 Model에게 전달하고 , Model이 Data를 업데이트하면 가서 다시 받아와서 업데이트된 Data를 View에 전달한다. Model과 View의 중간 다리 역할을 한다.
MVC 장점 1 : 대부분의 코드가 Controller(Activity || Controller)에 작성되어서 , 코드 해석이 쉬움.
MVC 장점 2 : Model과 View가 분리된 상태로 존재하기 때문에 , Model의 재사용이 가능하다. 즉, Model이 독립적으로 존재하기 때문에 재사용이 가능함.
MVC 단점 1 : 대부분의 코드가 Controller(Activity || Controller)에 작성되었기 때문에 , 기능이 추가 될수록 코드가 누적되면서 Legacy한 코드가 누적 될 수 있는 위험이 존재함. 따라서 실제로 Legacy한 코드가 감당 할 수 없을 만큼 커지게 된다면 , 롤꼴난다.
MVC 단점 2 : View와 Model의 결합도가 높아서 , Test Code 작성이 어려움.
MVC 패턴 근황 : 단점이 극악이라 별로 사용되지 않는 패턴임. 주로 앱에 많은 코드가 필요하지 않고 , 빠르게 앱을 작성해야 한다면 MVC 만한게 없다 이거야.
Unsplash 사이트를 활용해서 RandomImage를 불러오는 앱을 만들면서 공부 할거임.
MVP 패턴이란 , Model + View + Presenter의 약자로 , 기존 MVC 패턴의 View와 Model의 결합도를 높아서 테스트 코드 작성이 어려웠던 단점을 해결하기 위해서 등장한 패턴이야.
User가 View를 통해서 입력을 하게 되면 , View는 Presenter에 Event를 전달하게 되고 , 다시 Presenter는 Model에 Data 업데이트를 요청하고 , Data를 다시 가져온다. 가져온 Data를 Interface를 통해서 View에 전달하고 , View는 화면을 갱신해서 User에게 보여준다. Model과 View의 역할은 MVC와 비슷하지만 , Controller 대신에 Presenter를 사용한다.
MVP 패턴의 Model은 Data를 가지며 , Data를 처리 및 관리하는 역할을 한다. 또한 Presenter || View에 종속적이지 않아서 재사용이 가능하다. 또한 , NetworkApi && Data Cashing && Database등이 포함되고 Repository Pattern을 사용하는 경우는 , Repository도 포함된다.
MVP 패턴의 View는 User에게 보일화면을 표현하는데 , Model로부터 얻은 Data를 View에서 보여주며 , Activity || Fragment 등이 여기에 포함됨.
MVP 패턴의 Presenter는 View와 Model 사이의 중간다리 역할을 한다. 사용자가 무언가해서 발생한 이벤트를 View가 전달해주면 , Model에서 Data를 가져와서 View에 전달한다.
MVP 패턴 장점 1 : View와 Model간의 의존성이 없음. (=> Presentor가 존재하기 때문이야. && MVC 패턴에서의 파란박스가 없잖아)
MVP 패턴 장점 2 : UI 로직은 View에 , 나머지 로직은 Model에서 분리하였고 , 중간에 연결해주는 Presentor만 남아있기 때문에 , 단위테스트에 용이함.
MVP 패턴 단점 1 : View에서 Presenter를 직접 생성하기 때문에 , View와 Presenter의 의존성이 높고 , View와 Presenter는 1:1 관계를 유지(1개 있으면 다른 1개도 있어야해)해야 하기 때문에 , View가 많아지면 , Presenter도 많아진다.
MVP 패턴 단점 2 : View와 Model을 연결해 주는 것이 Presenter이기 때문에 , 앱의 기능이 많아 질 때마다 Presenter 내부의 코드의 양이 많아짐. 여기서 Legacy Code가 양산 될 가능성이 있음.
MVP 패턴 근황 : MVP 패턴은 앱을 구성하는 코드를 모듈화 시킬 수 있어서 , 협업시 자주 사용된다. 또한 , 테스트 코드 작성이 용이해서 앱의 유지보수가 쉽다.
MVVM 패턴이란 ? Model , View , ViewModel의 약자로 , MVP 패턴에서 , View와 Presenter가 1대1로 매칭되어야 하기 때문에 강하게 결합되어 있다는 문제점이 있었어. 이를 보완하기 위해서 MVMM 패턴이 등장하게 되었다.
MVVM 패턴에서는 별도로 DataBinding과 LiveData를 통해 View와 ViewModel 사이의 결합도롤 끊는데 , 집중하였다.
User가 View를 통해 Data를 입력하게 된다. View는 ViewModel에 이벤트를 전달하게 되고 , 다시 ViewModel은 Model에 Data 갱신을 요청하게 되고 , Data를 불러오게 된다. View는 ViewModel을 관찰하고 있고 , ViewModel에서 업데이트 된 Data를 LiveData에 넣는다. 그러면 View에 직접적으로 화면에 업데이트 하라고 명령하지 않아도 View에서는 이미 ViewModel을 관찰하고 있기 때문에 Data 변화를 알아차리고 자동으로 화면을 갱신한다. 이러한 View의 관찰을 통해 ViewModel과 View의 결합도를 낮출 수 있고 View와 ViewModel의 관계는 1:N관계가 된다.
MVVM 패턴의 Model은 Data를 가지면 사용되는 Data를 처리를 한다. View 또는 ViewModel에 종속적이지 않아서 , 재사용이 가능하다. Model에는 NetworkApi와 DataCashing , Database등이 포함이 된다. Repository 패턴을 사용하는 경우 , Repository도 포함이 된다.
MVVM 패턴의 View는 User에게 보일 화면을 표현을 한다. Model에서 얻은 Data를 View에서 보여주게 되며 , Activity || Fragmemt등이 여기에 포함이 된다. MVP와 차이점은 ViewModel은 직접 참조하지 않아도 , Data를 관찰해서 UI를 갱신한다는 것이다. 따라서 Data의 변화를 알아차리고 자동으로 화면을 갱신 할 수 있어.
MVVM 패턴의 ViewModel은 Model과 상호작용을 하며 , View에 종속적이지 않아서 1:N 구조를 가집니다. MVVM 패턴 중 가장 큰 특징은 , View가 어떠한 종속성도 가지지 않는다는 점이다. 그래서 ViewModel을 다른 View에서도 사용 할 수 있다.
MVVM 패턴 장점 1 : DataBinding과 LiveData를 사용하기 때문에 , View과 Data를 실시간으로 관찰하고 , 이를 자동으로 Update 할 수 있다는 것이야. 그로 인해서 , ViewModel에서는 View에 대한 결합도를 낮출 수 있고 , 1:N 관계가 되어서 , 여러개의 View에서 하나의 ViewModel을 활용 할 수 있어.
MVVM 패턴 장점 2 : LiveData가 생명주기를 인지하기 때문에 , 생명주기를 관리하는데에도 용이하다.
MVVM 패턴 장점 3 : View는 ViewModel을 알지만 , ViewModel은 View를 알지 못하고 , ViewModel은 Model을 알지만 , Model은 ViewMoel을 알지 못한다. 한쪽 방향으로만 , 의존관계가 있어서 , 각 Model 별로 분리해서 개발 할 수 있다.
MVVM 패턴 장점 4 : UI로직과 비즈니스 로직이 분리되어 있기 때문에 , 단위 테스트 작성도 수월하다는 것이 장점이야.
MVVM 패턴 단점 1 : 다른 패턴에 비해서 복잡하고 설계하는 것이 어렵다.
MVVM 패턴 단점 2 : DataBinding , LiveData 등과 같은 , 옵저빙 할 수 있는 라이브러리를 필수적으로 학습해야 된다 라는 것도 , 단점이야. 하지만, 한 번 익숙해지면 , 확장성 측면에서 좋기 때문에 , 유지 보수 하는데 큰 어려움이 없다.
MVI 패턴이란 , Model , View , Intent 의 약자로 , MVVM에서 상태문제와 부수효과라는 문제점이 있었는데 이를 해결하였다. 상태문제는 MVVM은 여러 상태를 관리하기 때문에 , 의도하지 않는 방향으로 흘러가는 것을 말한다. 부수효과는 원래 목적과는 다르게 다른 효과가 나타나는 상태를 말한다. 이러한 문제를 보완하기 위해 JavaScript의 리덕스를 기반으로 한, MVI가 등장하였다.
MVI 패턴은 , MVP나 MVVM 패턴과 유사하지만 , 인텐트와 상태라는 새로운 개념이 도입되었다. 따라서 단방향으로 하나의 상태를 관리하는 선순환 원칙이 적용되어 , 상태충돌이 발생하지 않는다.
User가 Intent를 통해 Model의 상태를 전달한다. 그러면 Model 안에서는 전달받은 상태에 대해 Data를 처리하고 , 그 결과를 담은 상태를 View에 전달한다. View는 Model로부터 전달된 상태를 받아 , 그에 맞는 화면을 User에게 보여준다. 이러한 일들은 계속해서 반복되며 , 선순환 구조를 가져오게 됩니다.
MVI 패턴에서 Model은 앞에서 살표보았던 Model들과는 다르다. 유일한 상태와 Data를 가지고 있는 불변 객체이다. 예를 들어 , UI에서 DataLoading , LoadData , Error 등 다양한 상태를 가질 수 있다. 따라서 Model은 상태에 대한 View가 어떤 것을 화면에 렌더링 해야 하는지를 말해주는 응답이야.
MVI 패턴에서 View는 User에게 보일 화면을 표현합니다. Model로부터 상태를 받아 , 화면에 표시하는 로직이 정의된 곳이야.
MVI 패턴에서 Intent는 우리가 아는 안드로이드에서의 Intent와는 다릅니다. App내에서 발생하는 Action을 나타내고 , 이것을 App 내의 상태를 바꾸려는 의도 , 인텐트라고 표현한다. 즉, Model에게 App의 상태를 전달한다. User는 모든 UI 변화에 대해서 , 이 Intent를 통해 이벤트를 전달하게 된다.
MVI 패턴에서 SideEffects는 상태 변경이 필요 없는 API 또는 DB 접근과 같은 이벤트를 발생시키는데 , 예를 들어 , Toast Pop Up을 실행시키는 Evene가 있다.
MVI 패턴 장점 1 : MVI 패턴의 가장 큰 장점은 하나의 상태만 관리하기 때문에 상태 충돌이 없다는 점이다. 하나의 상태를 관리함으로서 Data가 단방향으로 흐르게 되고 , Debugging이 쉽다.
MVI 패턴 장점 2 : 단방향의 선순환 구조이기 때문에 , 흐름을 이해하기 쉬어 로직에 대한 예측이 가능하다.
MVI 패턴 장점 3 : 각각의 출력값이 불변값이기 때문에 , Thread 안정성이 보장이 된다.
MVI 패턴 장점 4 : 각 구성요소가 자체 책임을 수행함에 따라 , 결합도가 낮아지게 된다.
MVI 패턴 단점 1 : 기존의 다른 패턴들에 비해 LearningCurver가 매우 높다. 따라서 함께 프로젝트를 하는 팀원들이 이 패턴에 대해 익숙하지 않으면 일을 이해하는데에 많은 시간이 할애된다.
MVI 패턴 단점 2 : 작은 UI 변경도 Intent로 시작하여 , 한 Cycle을 통과하여야 하기 때문에 , 너무 많은 작업들을 거쳐야 하고 , 그에 따라 반드시 Intent와 상태가 필요하다. 그로 인해서 보일러플레이트 코드가 발생 할 수 있고 , 또한 , Intent , 상태 , SideEffect등 모든 상태에 대해서 객체를 생성해야 하기 때문에 , 메모리 관리에 유의해야 한다. 하지만 , 하나의 상태로 선순환구조로 동작하기 때문에 , Debugging과 테트가 쉽다는 강저미 있음.
