1-1) MVC 패턴이란? (Model-View-Controller Pattern)
MVC 패턴은 애플리케이션, 프로젝트를 구성할 때, 그 구성요소를 세가지의 역할로 구분한 패턴이다.
- M( = Model) : 애플리케이션의 정보, 데이터를 나타낸다. 즉, 데이터베이스, 처음에 정의하는 상수, 초기화값, 변수 등을 뜻한다. 또한 이러한 데이터들의 가공을 책임지는 컴포넌트를 의미한다.
1) 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
=> 예를 들어, 화면안에 네모박스에 글자가 표현된다면, 네모박스의 화면 위치 정보, 네모박스의 크기정보, 글자내용, 글자의 위치, 글자의 포맷 정보 등을 갖고 있어야 한다.
2) 뷰나 컨트롤러에 대해서 어던 정보도 알지 말아야 한다
=> 데이터 변경이 일어났을 때, 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성 값을 가지만 안된다는 것이다.
3) 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
=> 모델의 속성 중 텍스트 정보가 변경이 된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 한다. 또한, 모델은 재사용이가능해야 하며, 다른 인터페이스에서도 변하지 않아야 한다.
- V( = View) : input텍스트, 체크박스 항목과 같은 사용자 인터페이스 요소를 의미한다. 즉, 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당하며, 데이터를 기반으로 사용자들이 볼 수 있는 화면이다.
1) 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
=> 화면에 글자를 표시하기 위해, 모델이 갖고있는 정보를 전달받게 되는데, 그 정보를 유지하기 위해서 임이의 뷰 내부에 저장하면 안된다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때, 필요한 정보들은 저장하지 말야야 한다.
2) 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 한다.
=> 모델과 같은 자기 자신 빼고는 다른 요소들은 참조하거나 어떻게 동작하는지 몰라야한다. 그냥 뷰는 데이터를 받으면 화면에 표시하는 역할만 가져야 한다.
3) 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
=> 모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현해야 하며, 재사용가능하게끔 설계를 해야하며, 다른 정보들을 표현할 때 쉽게 설계를 해야한다.
- C( = Controller) : 데이터와 사용자인터페이스의 다리역할을 한다.
1) 모델이나 뷰에 대해서 알고 있어야 한다.
=> 모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 갖고 있는데 이를 컨트롤러가 중재한다.
2) 모델이나 뷰의 변경을 모니터릴 해야 한다.
=> 모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야한다. 또한, 애플리케이션의 메인 로직은 컨트롤러가 담당한다.
1-2) MVC패턴의 장/단점
장점
- 비지니스 로직과 UI로직을 분리하여 유지보수를 독립적으로 수행할 수 있다.
- 모델과 뷰가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리하다.
- 중복 코드를 줄일 수 있다.
단점
- 뷰와 모델이 서로 의존성을 갖게 된다. => 컨트롤러에 의해서 하나의 뷰에 연결될 수 있는 모델도 여러 개가 될 수 있다.
1-3) MVC패턴의 동작 과정
- 사용자의 Action들은 Controller에 들어온다.
- Controller는 사용자의 Action를 확인하고, Model을 업데이트한다.
- Controller는 Model을 나타내줄 View를 선택한다.
- View는 Model을 이용하여 화면을 나타낸다.
2-1) MVP 패턴이란? (Model-View-Presenter Pattern)
Model, View, Presenter로 구성된 디자인 패턴입니다. MVP의 핵심 설계는 MVC와 다르게 UI(View)와 로직(Model)을 분리하고, 서로 간에 상호작용을 다른 객체(Presenter)에 그 역할을 줌으로써, 서로의 영향(의존성)을 최소화하도록 한다.
- M ( = Model) : 뷰 또는 프레젠터 등 다른 요소에도 의존적이지 않은 독립적인 영역이다.
- V ( = View) : 모델에서 처리된 데이터를 프레젠터를 통해 전달받아서 유저에게 보여준다
1) 유저 행동 및 액티비티 생명 주기 상태 변경을 주시하며, 프레젠터에 전달하는 역할을 한다.
2) 프레젠터를 이용하여 데이터를 주고받기 때문에 프레젠터에 매우 의존적이다
- P ( = Presenter) : 모델과 뷰 사이의 매개체
1) MVC의 컨트롤러와 비슷하지만, 뷰에 직접 연결되는 대신 인터페이스를 통해 상호작용을 한다는 차이점이 있다.
2) 인터페이스를 통해 상호작용하므로, MVC가 가진 테스트 문제와 함께 모듈화/유연성 문제를 해결할 수 있다.
3) 뷰에게 표시할 내용만 전달하며 어떻게 보여줄 지는 뷰가 담당한다.
2-2)MVP 패턴의 장/단점
장점
- MVC와는 다르게 코드가 깔끔해지고, Model과 View의 결합도를 낮추면, 새로운 기능 추가 및 변경을 할때 마다 관련된 부분만 코드를 수정하면 되기 때문에 확장성이 개선된다.
- UI,DATA 각각 파트를 나누어서 해야할 일이 명확해지고, 쉽고 빠른 코딩이 가능하다.
단점
- 어플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 강해진다.
2-3) MVP 패턴의 동작 과정
- 사용자의 Action들은 뷰를 통해 들어온다.
- 뷰는 데이터를 프레젠터에 요청한다.
- 프레젠터는 모델에게 데이터를 요청한다.
- 모델은 프레젠터에서 요청받은 데이터를 응답한다.
5 .프레젠터는 뷰에게 데이터를 응답한다.- 뷰는 프레젠터가 응답한 데이터를 이용하여 화면을 나타낸다.
3-1) MVVM 패턴이란? (Model-View-View Model Pattern)
MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현한 패턴이다. Command 패턴과 Data Binding을 이용하여 뷰와 뷰모델 사이의 의존성을 없애며, 뷰모델과 뷰는 1:n 비율이다.
- M( = Model) : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분이다.
- V ( = View) : 사용자에서 보여지는 UI 부분이다.
- VM ( = View Model) : 뷰를 표현하기 위해 만든 뷰를 위한 모델이다. 뷰를 나타내 주기 위한 모델이자 뷰를 나타내기 위한 데이터 처리를 하는 부분이다.
3-2) MVVM 패턴의 장/단점
장점
- 뷰와 모델 사이의 의존성이 없다.
- Command 패턴과 Data Binding을 사용하여 뷰와 뷰 모델 사이의 의존성이 없다.
==> 각각 부분이 독립적이기 때문에 모듈화하여 개발할 수 있다
단점
- 뷰 모델의 설계 자체가 어렵다.
3-3) MVVM 패턴의 동작 과정
- 사용자의 Action들은 뷰를 통해 들어온디.
- 뷰에 Action이 들어오면, Command 패턴으로 뷰 모델에 Action을 전달한다.
- 뷰 모델은 모델에게 데이터를 요청한다.
- 모델은 뷰 모델에게 요청받은 데이터를 응답한다.
- 뷰 모델은 응답 받은 데이터를 가공하여 저장한다.
- 뷰는 뷰 모델과 Data Binding하여 화면을 나타낸다.
