MVC
MVC (ModelViewController)는 정보 프리젠 테이션 로직 및 사용자 상호 작용을 분리하는 컴퓨터 사용자 인터페이스 개발 모델입니다. 모델에는 응용 프로그램 데이터 및 비즈니스 로직이 포함되어 있습니다. 컨트롤러는 사용자 입력을 명령으로 변환하여 모델과보기로 전달할 책임이 있습니다. 이것은 위키 백과의 설명입니다.
이 모델은 원래 SmallTalk-80 (1979)에서 작업 할 때 Trygve Reenskaug에 의해 원래 설계되었으며, 처음 모델-뷰-컨트롤러 편집자라고 불 렸습니다. 나중에, "디자인 패턴 : 재사용 가능한 객체 지향 소프트웨어의 요소"라는 책의 심층적 인 소개를 통해 MVC는 완전히 인기를 얻었습니다.
MVC의 세 부분을 구성하는 책임과 기존 JavaScript 프레임 워크가 제공하는 내용을 이해하여 이러한 프레임 워크를 더 잘 사용할 수 있습니다. 다음으로, 먼저 MVC를 구성하는 세 부분을 전달하여 각 부분의 책임이 무엇인지 배우게됩니다.
모델
모델은 응용 프로그램 데이터를 관리합니다. 모델 데이터가 변경되면 리스너에게 알림을받습니다. 알림을받은 후에도 청취자는 해당 변경을 수행합니다.
보다
보기는 현재 상태 모델의 시각적 표현입니다. 보기는 모델의 변경 사항을 관찰하고 모델이 변경 될 때 알림을 받고 뷰가 자체적으로 업데이트 될 수 있습니다. 일반적으로 템플릿 엔진을 사용하여 모형을보기에서 렌더링합니다.
컨트롤러
컨트롤러는 모델과 뷰 사이의 중재자입니다. 이 작업은 모델이 변경 될 때보기를 업데이트하고 사용자가보기를 작동 할 때 모델을 업데이트하는 것입니다.
Javascipt MVC 프레임 워크 비교
다른 사람들은 다른 비교 방법을 가지고 있으며, 열쇠는 당신이주의를 기울이는 것에 달려 있습니다.
1. 프레임 워크의 URL 라우팅, 데이터 저장, 구현보기 등의 세부 사항에 더 많은 관심을 기울이면, 이에 초점을 맞출 수 있습니다.
2. 프레임 워크의 특정 예에 더주의를 기울이면 동일한 데모를 위해 다른 JavaScript MVC 프레임 워크를 사용하는 오픈 소스 프로젝트가 있습니다. 각 프레임 워크의 특정 응용 프로그램의 차이점을 명확하게 볼 수 있습니다. 다음은 TODOMVC의 공식 웹 사이트입니다
MVC의 이점은 우리에게 가져옵니다.
1. 유지하기 쉬운
2. 모델보기의 분리는 비즈니스 로직을 더 잘 테스트 할 수 있음을 의미합니다.
3. 코드를 더 잘 재사용 할 수 있습니다
4. 모듈 식 개발은 노동 분할을 더 명확하게 만들 수 있고, 어떤 사람들은 비즈니스 논리에 집중할 수 있으며, 어떤 사람들은 사용자 인터페이스에 집중할 수 있습니다.
5. 클래식 MVC 모델을 검토 한 후, 우리는 응용 프로그램의 계층화 개념과 각 계층의 책임을 이해합니다. 동시에, 우리는 모든 JavaScript MVC 프레임 워크와 우리가 설명하는 클래식 MVC 모델의 차이점을 식별 할 수 있어야합니다. 이러한 방식으로 MVC 프레임 워크를 선택할 때 모델, 뷰, 컨트롤러가 구현되는 방법, 심지어 특정 코드를 구현하는 방법에 중점을 두어 가장 적합한 JavaScript MVC 프레임 워크를 더 잘 선택할 수 있도록 집중해야합니다.
MVVM
MVVM의 전체 이름은 Model View ViewModel입니다. 이 아키텍처 모델은 원래 Microsoft의 Martinfowler가 Microsoft의 프레젠테이션 레이어 설계 모델의 사양으로 제안했습니다. MVC 모델의 파생물입니다. MVVM 모델의 초점은 HTML5, [2] [3] Wind
이 모델의 구현의 대부분은 뷰 계층에서 데이터 바인딩을 선언하여 다른 계층과 분리되어 프론트 엔드 개발자와 백엔드 개발자 간의 노동 분할을 용이하게합니다. 프론트 엔드 개발자는 HTML 태그에서 뷰 모델에 바인딩 데이터를 작성합니다. Model 및 ViewModel은 응용 프로그램 개발 논리를 통해이 두 계층을 유지하는 백엔드 개발자입니다.
최근 몇 년 동안 MVVM 모델은 JavaScript로 구현되기 시작했습니다. 현재 비교적 성숙한 프레임 워크에는 Knockoutjs, Kendo MVVM 및 Knockback.js가 포함됩니다. MVVM 모델의 각 부분의 특정 책임과 예제 코드를 보려면 Knockoutjs를 예로 들어 봅시다. 동시에이 모델을 사용하여 개발하기위한 장점과 단점을 이해합니다.
모델
다른 MV* 가족 구성원과 마찬가지로 모델은 응용 프로그램에 필요한 특정 필드 또는 데이터, 사용자 정보 [사용자 이름, 아바타, 이메일, 전화 번호] 또는 음악 정보 [노래 이름, 출시 연도, 앨범]과 같은 일반적인 필드 특정 데이터를 나타냅니다.
모델은 데이터 정보에만 초점을 맞추고 어떤 행동에도 신경 쓰지 않습니다. 데이터를 형식화하거나 브라우저의 데이터 표시에 영향을 미치지 않으며, 이는 그의 책임이 아닙니다. 데이터 서식은 뷰 계층의 작업이며, 비즈니스 로직 계층은 뷰 모델에 캡슐화되어 모델과 상호 작용합니다.
모델 계층에서 수행 된보다 예상치 못한 동작은 데이터를 확인하는 것입니다. 예를 들어, 사용자가 이메일을 입력하면 이메일 형식이 올바른지 확인하십시오.
Knockoutjs에서는 모델이 기본적으로 위의 정의에 따라 구현되지만 모델 데이터를 읽고 쓰기 위해 Ajax 호출 서버 서비스가 있습니다.
보다
보기는 사용자와 직접 상호 작용하는 응용 프로그램의 일부를 나타냅니다. 뷰 모델의 상태를 나타내는 대화식 UI입니다. 견해는 수동적 인 것이 아니라 활동적인 것으로 간주됩니까? 이 문장은 수동적보기가 응용 프로그램의 모델 도메인에 신경 쓰지 않으며 모델의 도메인이 컨트롤러에서 유지된다는 것을 의미합니다. MVVM의 활성보기에는 데이터 바인딩, 이벤트 및 모델 및 뷰 모델의 동작을 이해해야합니다. 이러한 동작은 속성에 해당 할 수 있지만,보기는 여전히 뷰 모델의 이벤트에 응답해야하며, 뷰는 상태를 제어 할 책임이 없습니다.
Knockoutjs의 View Layer는 간단한 HTML 문서로, 뷰 모델의 데이터 선언과 관련이 있습니다. 동시에, Knockoutjs의 뷰 레이어는 ViewModel에서 얻은 데이터를 표시하고 명령을 ViewModel로 전달하며 뷰 모델의 변경된 상태를 업데이트합니다.
뷰 모델
ViewModel은 데이터 변환에 특별히 사용되는 컨트롤러라고 생각할 수 있습니다. 모델의 정보를보기의 정보로 변환 할 수 있으며 동시에 명령을보기에서 모델로 전달할 수 있습니다.
이런 의미에서 ViewModel은 모델처럼 보이지만보기의 많은 디스플레이 로직을 제어합니다. 동시에 ViewModel은보기의 상태를 유지하고 View의 행동 및 이벤트에 따라 모델을 업데이트하는 몇 가지 방법을 노출시킵니다.
요약하면, 뷰 모델은 UI 계층 뒤에 위치하며, 뷰에 데이터를 노출시키는 것은 뷰 계층의 데이터 소스 및 동작으로 간주 될 수 있습니다.
Knockoutjs는 ViewModels를 UI에 표현 된 데이터 및 동작의 표시로 해석합니다. 유지 해야하는 데이터 모델은 아니지만 사용자가 저장 한 데이터를 보유 할 수 있습니다. Knockout의 ViewModels는 JavaScript 객체를 사용하여 구현되며 HTML 태그에 대해 신경 쓰지 않아도됩니다. 이 추상 방법은 구현을 간단하게 유지할 수 있습니다.
이점:
1.MVVM은 병렬 개발을 더 쉽게 만들어 프론트 엔드 개발과 백엔드 개발자가 서로 영향을 미치지 않습니다.
2. 뷰 계층을 추상화하여 코드의 비즈니스 로직 감소
3. ViewModel은 이벤트 중심보다 테스트하기가 더 쉽습니다
4. ViewModel의 테스트는 UI 자동화 및 상호 작용에 대해 신경 쓰지 않아도됩니다.
결점:
1. 간단한 UI의 경우 MVVM 사용이 너무 무겁습니다.
2. 선언적 데이터 바인딩은 명령 코드가 브레이크 포인트를 쉽게 설정할 수 있기 때문에 디버깅에 도움이되지 않으며이 모드는 그러한 중단 점을 설정하는 데 도움이되지 않습니다.
3. 데이터 바인딩은 사소한 응용 프로그램에서 많은 부기 유지를 만들 수 있습니다. 또한 바인딩이 바운드 객체보다 더 복잡한 더 복잡한 상황으로 끝나기를 원하지 않습니다.
4. 대규모 응용 분야에서는 많은 일반화를 얻기 전에 뷰 모델 레이어를 설계하기가 어렵습니다.