-디자인 패턴이 필요한 이유
모든 디자인 패턴들은
화면에서 보여지는 로직과
실제 데이터들이 처리되는 로직을 분리한다.
그리해야
협업, 유지보수, 테스트에 용이하다.
즉 쾌적하고 편리한 개발환경 구축가능하기 때문이다.
-디자인 패턴 종류
MVC, MVP, MVVM 모델등이 있다.
-MVC 모델
Model, View, Controller 로 이루어져있다.
Model
데이터, 데이터의 상태(State), 비지니스 로직이 들어가 있다.
View
Model를 표현한다.
사용자가 입력한 값을 Controller에게 전달한다.
Controller
Model을 통해 사용자가 입력한 데이터들을 받는다.
처리된 데이터 값들을 View로 넘긴다.
Model과 View사이에서 행동한다.
-대략적인 작동방식
사용자의 Action들은 Controller에 들어온다.
Controller는 사용자의 Action를 확인하고, Model을 업데이트합니다.
Controller는 Model을 나타내줄 View를 선택합니다.
View는 Model을 이용하여 화면을 나타냅니다.
View는 Controller를 인식하지 못한다.
Controller는 View를 선택할 뿐, 직접 업데이트를 시키진 않는다.
Controller와 View는 1:N의 관계, 여러개의 View를 Controller가 선택한다.
-장점
단순하고 많이 쓰는 방식이다.
-단점
View와 Model이 서로 의존성있다. 유지보수에 어렵다.
너무 많은 것들이 Controller에 들어가게 된다.
-MVP 모델
Model, View, Presenter
Controller 대신에 Presenter가 등장했다.
Presenter
View에서 요청한 정보를 Model로 부터 가공해서 View로 전달하는 부분
-대략적인 작동방식
View로 사용자의 입력이 들어온다
View에서 Presenter에 작업요청 (1:1)
Presenter에서 Model에게 데이터 요청
Model이 Presenter에게 데이터를 전달
Presenter는 View에게 데이터 응답
View가 데이터 받은걸로 화면에 출력
-장점
View와 Model 둘 사이의 의존성이 없어짐
-단점
대신 View와 Presenter가 강한 의존성을 가지게 됨
복잡할수록 더 강한 의존성을 가지게 된다.
비슷한 로직을 필요하는 화면이 많을수록 중복되는 코드들이 늘어난다.
-MVVM 모델
Model, View, ViewModel 로 이루어져있다.
ViewModel
View를 표현하기 위해 만든
View를 위한
Model 이다.
View를 나타내기 위해 데이터를 처리한다.
- 대략적인 작동방식
View를 통해 사용자의 Action이 들어온다
View가 Command 패턴으로 View Model에 Action을 전달
View Model이 Model에게 데이터를 요청하고 Model은 데이터를 ViewModel로 넘겨준다
ViewModel은 넘겨받은 데이터들을 가공해서 저장한다.
view는 ViewModel과의 Data Binding을 통해 자동으로 화면에 출력
View와 ViewModel 사이의 의존성이 없다.
ViewModel과 View는 1:N 관계
-장점
각각의 부분이 전부 독립적이기에 모듈화하여 개발 가능
-단점
Databinding이 필수
간단한 View 제작시 굉장히 비효율적임
ViewModel의 설계가 쉽지않다
- 결론
각자 알맞는 사용처가 있다.
참고한 사이트
https://magi82.github.io/android-mvc-mvp-mvvm/
https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/
'프로그래밍 공부 > Spring' 카테고리의 다른 글
| Spring Framework 개발 순서 (0) | 2020.02.21 |
|---|