MVC 란 ?
상호 작용 어플리케이션을 구현 할 때
Model, View, Controller 구조로 각각을 분리해서 패턴화 한 것.
MVC 구성요소
사용 이유?
: 상호 작용 어플리케이션을 구축하다 보면 아래와 같은 문제점 들로 인하여
유연성을 갖춘 시스템 구축이 필요해 짐
문제점?
- 고객의 요구에 따라 인터페이스 변경이 잦음
- 릴리즈 되는 어플리케이션 이라면 항상 인터페이스 변경의 도전을 받게 됨
- 사용자에 따른 다른 요구 사항
: 키보드, 마우스
- 같은 데이터가 다른 방법들로 보여지게 됨
- 자동화된 UI 테스트가 어려울 때
동작
구현
( 1~ 6 기본 구현 ) ( 7 ~ 10 애플리케이션에 유연성을 제공 )
1.핵심 기능과 사람- 컴퓨터 상호작용 기능을 분리한다.
2.변경전파 메커니즘을 구현한다.
3.뷰를 설계하고 구현한다.
4.컨트롤러를 설계하고 구현한다.
5.뷰-컨트롤러 관계를 설계하고 구현한다.
6.MVC의 설정 코드를 구현 한다.
7.동적 뷰를 생성한다.
8.컨트롤러를 플러그처럼 장착할 수 있도록 구현한다.
9.계층적 뷰와 컨트롤러를 위한 인프라를 구축한다.
10.결합도를 낮춰 시스템 종속성을 줄여간다.
장점
1.동일한 모델로부터 여러 뷰들을 표시할 수 있다.
2.뷰들이 동기화 된다.
3.뷰와 컨트롤러를 플러그처럼 장착할 수 있다.
4.룩앤필의 교환가능성을 제공한다.
5.프레임워크로 확장 할 수있다.
단정
1.복잡성이 증가한다.
2.엄청나게 많은 업데이트들이 동시에 진행될 수 있다.
3.뷰와 컨트롤러가 밀접히 관련된다.
4.뷰 및 컨트롤러가 모델에 밀접히 결합되어 있다.
5.뷰가 데이터에 액세스하는 일반적인 과정은 비효율적인 경향이 있다.
6.다른 플랫폼에 이식시킬 때 뷰와 컨트롤러를 변경하지 않을 수 없다.
7.최신 사용자 인터페이스 툴에 MVC를 적용하기 어렵다.
'Design Pattern' 카테고리의 다른 글
[Design pattern] Micro Kernel (0) | 2013.02.21 |
---|---|
[Design pattern] PAC (0) | 2013.02.21 |
[Design pattern] Command Processor (0) | 2013.02.21 |
[Design pattern] Proxy (0) | 2013.02.21 |
[Design pattern] Master-Slave (0) | 2013.02.21 |