Previous chapter
Model-View-Controller
UI와 데이터를 분리하자!
•
여러개의 컴포넌트의 결합도가 너무 높다면, 작은 변경 하나만으로 프로그램 전체를 수정해야 함.
•
어플리케이션의 확장성을 높이기 위해, UI로부터 비즈니스 로직을 분리해 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향없이 쉽게 고치는 패턴
선거를 진행하면 진행한 선거 결과가 있을 것이다.
이를 어떻게 보여주는가(View)를 데이터와 분리시키는 것.
Model
데이터 정의 클래스
소프트웨어 응용과 클래스 내의 논리적 데이터 기반 구조를 표현함. 사용자 인터페이스에 관한 어떠한 정보도 가지고 있지 않음.
•
논리적 데이터의 집합
•
사용자에게 화면을 보여주는데 있어서 사용한 데이터
•
어떤 UI정보도 가지고 있지 않음.
View
UI 클래스
사용자 인터페이스 내의 구성요소를 표현하는 클래스의 집합
•
Model을 시각적으로 표현
•
UI 내의 구성요소를 표현하는 클래스를 포함
•
사용자가 View에서 동작을 수행할 때의 이벤트는 Controller에 전달이 되고, Controller는 이를 수행한다.
Controller
입력 클래스
사용자의 입력을 기반으로 MODEL이 변경됨.
•
사용자가 View를 통해 입력하면 Model을 변경해줌.
•
변경된 Model을 View에 반영
•
Model과 View 사이의 통신을 중개하는 역할을 함.
Passive & Active
MVC패턴은 View의 개수가 1개인가, 2개이상인가에 따라 다음과 같이 정의된다.
Passive Model
패시브모델은 2가지 처리과정으로 분류할 수 있다.
1.
controller는 입력을 얻어 해당 서비스를 바로 Model에 전달한다.
2.
서비스 결과를 View에 갱신시키기 위해 Update를 알리고 View는 Model로부터 데이터를 얻어 갱신한다.
Active Model
액티브 모델은 Passive model의 중간에 Observer Pattern이 추가된 형태이다.
모델이 별도의 Observer를 두어 Controller와 View의 갱신된 내용을 관리하는 형식이다.
MVC 패턴 정의
Context(상황)
•
사용자가 데이터를 변경하면 시스템의 데이터 저장소에 저장된다.
•
정보가 데이터 저장소와 UI 사이에 전달되므로, 두 개체를 연결하여 코딩의 양을 줄이고 성능을 향상시키려 할 것이다.
•
UI보다 데이터 저장소가 더 자주 바뀐다.
Problem(문제점)
•
UI의 수정은 용이해야하며, 변경사항은 런타임에 바로 반영되어야한다.
•
또한 UI 수정 시에는 내부 코드에 영향을 줄 수 없다.
Solution(해결책)
•
시스템 구성 요소를 데이터와 디자인과 데이터 처리 담당으로 분리시켜 각각의 독립성을 유지할 수 있도록 한다.
•
사용자 인터페이스와 실제 동작 코드를 분리한다.
장점
•
복수의 뷰를 지원할 수 있다.
◦
뷰와 모델이 구분되어 모델이 직접 의존하지 않으므로 동일한 데이터로 여러개를 해먹을 수 있다.
•
변경사항을 바로 수용할 수 있다. UI요구사항이 급격하게 변하는 경우 데이터와 UI가 분리되므로 UI의 변경사항을 적용하더라도 모델에는 영향이 가지 않는다.
단점
•
복잡해진다.
◦
간접참조를 사용하므로 솔루션이 복잡해진다.
•
디버깅이 어렵다
◦
UI 코드의 이벤트 중심적 특성이 강해지기 때문에 디버깅이 어렵다.
•
빈번한 업데이트의 손실
◦
일부 뷰는 렌더링에 시간이 걸린다.
Next chapter