보고있는 대부분의 프레임 워크는 동일한 문제를 해결하지만 약간 다른 목표로 약간 다른 방식으로 수행합니다.
이 모든 프로젝트가 다음과 같은 범주의 문제를 해결할 것이라고 말하는 것이 공정하다고 생각합니다.
- 합리적인 기본 설정 제공
- 상용구 코드 줄이기
- BackboneJS 빌딩 블록 위에 애플리케이션 구조 제공
- 작성자가 앱에서 사용하는 패턴 추출
2011 년 12 월 이후로 구축 한 마리오네트는 다음과 같은 매우 뚜렷한 목표와 이상을 염두에두고 있습니다.
- 복합 애플리케이션 아키텍처
- 엔터프라이즈 메시징 패턴 영향
- 모듈화 옵션
- 증분 사용 (모두 필요 없음)
- 서버 잠금 없음
- 기본값을 쉽게 변경할 수 있도록하십시오
- 구성 / 오버 구성 코드
다른 프레임 워크 중 어느 것도 동일한 목표를 가지고 있지 않다는 말은 아닙니다. 그러나 마리오네트의 독창성은 이러한 목표의 조합에서 비롯된 것 같습니다.
복합 애플리케이션 아키텍처
WinForms와 C #을 사용하는 씩 클라이언트 분산 소프트웨어 시스템에서 5 년 이상 일했습니다. 데스크톱, 랩톱 (스마트 클라이언트), 모바일 장치 및 웹 응용 프로그램 용 앱을 구축했으며, 핵심 기능 세트를 공유하고 동일한 서버 백엔드와 여러 번 작업했습니다. 이번에는 모듈화의 가치를 배웠고 복합 응용 프로그램 설계의 길을 매우 빠르게 넘어 섰습니다.
기본 아이디어는 응용 프로그램의 런타임 환경을 "구성"하고 서로를 알 필요가없는 더 작은 개별 조각으로 처리하는 것입니다. 이들은 전체 복합 애플리케이션 시스템에 등록한 후 분리 된 메시지 및 호출의 다양한 수단을 통해 통신합니다.
나는 마리오네트를 백본의 복합 애플리케이션 아키텍처로 소개하면서 내 블로그에 이것에 대해 조금 썼습니다.
메시지 큐 / 패턴
동일한 대규모 분산 시스템은 메시지 큐잉, 엔터프라이즈 통합 패턴 (메시징 패턴) 및 서비스 버스를 이용하여 메시지를 처리했습니다. 이것은 무엇보다도 분리 된 소프트웨어 개발에 대한 나의 접근 방식에 막대한 영향을 미쳤습니다. 이 관점에서 단일 프로세스의 메모리 내 WinForms 응용 프로그램을보기 시작했고 곧 서버 쪽과 웹 응용 프로그램 개발이 이에 영향을 미쳤습니다.
이것은 내가 Backbone 애플리케이션 디자인을 보는 방식으로 직접 변환되었습니다. 고급 응용 프로그램 객체와 응용 프로그램 내에서 생성하는 각 모듈 모두에 대해 Marionette의 이벤트 수집기를 제공합니다.
모듈간에 보낼 수있는 메시지 (명령 메시지, 이벤트 메시지 등)에 대해 생각합니다. 또한 서버 측 통신을 이와 동일한 패턴의 메시지로 생각합니다. 일부 패턴은 이미 마리오네트로 향했지만 아직 패턴이 없습니다.
모듈화
코드의 모듈화는 매우 중요합니다. 잘 정의 된 진입 점과 출구 점이있는 단일 초점을 가진 작고 캡슐화 된 패키지를 작성하는 것은 크기와 복잡성이 큰 시스템의 필수 요소입니다.
마리오네트는 module정의를 통해 직접 모듈화를 제공합니다 . 그러나 나는 또한 RequireJS를 좋아하는 사람들도 알고 싶어합니다. 따라서 표준 빌드와 RequireJS 호환 빌드를 모두 제공합니다.
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(아직 블로그 게시물이 없습니다)
증분 사용
이것이 마리오네트의 모든 부분에 적용되는 핵심 철학 중 하나입니다. 마리오네트 사용에 대한 "전부 또는 아무것도"요구 사항이 없습니다.
백본 자체는 모든 빌딩 블록 개체에 대해 매우 점진적이고 모듈 방식으로 접근합니다. 언제 어떤 것을 사용하고 싶은지 자유롭게 선택할 수 있습니다. 나는이 원칙을 강하게 믿고 마리오네트가 같은 방식으로 작동하도록 노력합니다.
이를 위해 Marionette에 내장 한 대부분의 작품은 독립형으로 구축되어 Backbone의 핵심 작품과 함께 작동하며 더욱 잘 작동하도록 제작되었습니다.
예를 들어, 거의 모든 백본 애플리케이션은 화면의 특정 위치에 백본보기를 동적으로 표시해야합니다. 또한 새로운 뷰를 배치 할 때 이전 뷰 닫기 및 메모리 정리를 처리해야합니다. 마리오네트가 Region등장하는 곳 입니다. 영역은 뷰를 작성하고 렌더링을 호출하고 결과를 DOM에 채우는 상용구 코드를 처리합니다. 그런 다음 뷰에 "닫기"방법이있는 경우 해당 뷰를 닫고 정리합니다.
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
그러나 지역을 사용하기 위해 마리오네트의 견해를 사용할 필요는 없습니다. 유일한 요구 사항은 개체의 프로토 타입 체인에서 특정 시점에 Backbone.View에서 확장하는 것입니다. close분석법, onShow분석법 또는 기타 방법 을 제공하기로 선택하면 Marionette 's Region에서 적시에 전화를 겁니다.
서버 잠금 없음
다양한 서버 기술을 기반으로 Backbone / Marionette 앱을 빌드합니다.
- ASP.NET MVC
- 루비 온 레일즈
- 루비 / 시나트라
- NodeJS / ExpressJS
- PHP / 슬림
- 자바
- 에를 랑
- ... 그리고 더
JavaScript는 브라우저에서 실행될 때 JavaScript입니다. 서버 측 JavaScript도 훌륭하지만 브라우저 기반 JavaScript를 작성하는 방법에 영향을 미치지 않습니다.
클라이언트가 사용하는 백엔드 기술과 백엔드 기술의 다양성으로 인해 어떤 이유로 든 단일 서버 측 기술 스택에 마리오네트를 고정시킬 수 없으며 잠그지 않을 것입니다. 상용구 프로젝트를 제공하지 않습니다. 루비 젬이나 npm 패키지는 제공하지 않습니다. Marionette에는 특정 백엔드 서버가 필요하지 않다는 것을 사람들이 이해하고 싶습니다. 브라우저 기반 JavaScript이며 백엔드는 중요하지 않습니다.
물론 언어와 프레임 워크에 패키지를 제공하는 다른 사람들을 전적으로 지원합니다. 나는 그 패키지를 Wiki에 나열하고 사람들이 필요에 따라 더 많은 패키지를 계속 빌드하기를 희망합니다. 그러나 그것은 마리오네트의 직접적인 지원이 아니라 지역 사회 지원입니다.
쉽게 기본값을 변경
상용구 코드를 줄이고 합리적인 기본값 (Tim Branyen의 LayoutManager에서 직접 "빌려온"아이디어)을 제공하려는 노력의 일환으로, 다른 개발자가 저와는 약간 다른 구현을 사용해야한다는 것을 알고 있습니다.
<script>기본적으로 Underscore.js 템플릿을 사용하여 템플릿의 인라인 태그를 기반으로 렌더링을 제공합니다 . 그러나 마리오네트에서 개체 Renderer및 / 또는 TempalteCache개체를 변경하여이를 대체 할 수 있습니다 . 이 두 객체는 렌더링 기능의 핵심을 제공하며, 특정 템플릿 엔진 및 템플릿로드 방법에 따라이를 변경하는 방법을 보여주는 위키 페이지가 있습니다.
Marionette v0.9를 사용하면 훨씬 쉬워집니다. 예를 들어 인라인 템플릿 스크립트 블록 사용을 미리 컴파일 된 템플릿으로 바꾸려면 렌더러에서 한 가지 방법 만 교체하면됩니다.
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
이제 전체 애플리케이션이 미리보기 템플릿을 사용하여 뷰의 template속성에 첨부 합니다.
비동기식 렌더링 뷰를 지원할 수있는 v0.9의 Marionette.Async 애드온도 제공합니다. 저는 마리오네트의 기본 행동을 최대한 쉽게 대체 할 수 있도록 지속적으로 노력하고 있습니다.
구성 코드
특정 상황에서 "컨벤션 오버 컨벤션"을 좋아합니다. 그것은 일을 끝내는 강력한 방법이며, 마리오네트는 솔직히 말해서 조금만 제공합니다. 다른 많은 프레임 워크, 특히 LayoutManager는 Marionette보다 구성에 대해 더 많은 규칙을 제공합니다.
이것은 목적과 의도로 이루어집니다.
의미 있고 빠른 방법으로 컨벤션을 작동시키려는 노력을 아는 데 충분한 JavaScript 플러그인, 프레임 워크, 애드온 및 애플리케이션을 구축했습니다. 속도로 수행 할 수 있지만 일반적으로 속도를 변경할 수 있습니다.
이를 위해 Marionette에 대한 "구성 코드"접근 방식을 사용합니다. 나는 동작의 변화를 바꾸는 정적 값으로 객체 리터럴을 제공 할 수있는 많은 "구성"API를 제공하지 않습니다. 대신, 주석이 달린 소스 코드와 실제 API 문서를 통해 각 객체가 가지고있는 메소드를 문서화하여 원하는 방식으로 Marionette를 변경하는 방법을 알려줍니다.
Marionette 객체에 깨끗하고 명확한 API를 제공함으로써 특정 객체 또는 Marionette의 동작을 전체적으로 대체하는 것이 비교적 간단하고 매우 유연한 상황을 만듭니다. 나는 "간단한"구성 API를 희생하여 원하는 방식으로 작동하도록 고유 코드를 제공하는 유연성을 요구합니다.
Marionette에서 "configure"또는 "options"API를 찾을 수 없습니다. 그러나 깨끗한 서명을 사용하여 각각 매우 구체적인 목적을 수행하는 많은 방법을 통해 마리오네트의 작동 방식을 쉽게 변경할 수 있습니다.
