PPT 다운로드 주소의 PDF 버전 : http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javaScript-application-architecture
참고 : Collation 과정에서 저자의 생각이 반복된다는 것을 알았으므로 일부는 그 중 일부를 삭제했습니다. 영어가 좋으면 영어 ppt를 직접 읽으십시오.
다음은이 기사의 주요 장입니다.
1. "JavaScript 대형 프로그램"이란 무엇입니까?
2. 현재 프로그램 아키텍처를 고려하십시오
3. 장기 고려
4. 브레인 스토밍
5. 제안 된 건축
5.1 디자인 패턴
5.1.1 모듈 이론
5.1.1.1 개요
5.1.1.2 모듈 모드
5.1.1.3 객체 자체 면적 크기
5.1.1.4 CommonJS 모듈
5.1.2 외관 모드
5.1.3 중재자 모드
5.2 건축에 적용하십시오
5.2.1 외관 - 핵심 추상화
5.2.2 중재자 - 프로그램 코어
5.2.3 면밀히 작동합니다
6. Pub/Sub Extension 게시 : 자동 등록 이벤트
7. Q & A
8. 인정
"JavaScript 대형 프로그램"이란 무엇입니까?
시작하기 전에 큰 JavaScript 사이트가 무엇인지 정의해 봅시다. 많은 숙련 된 JS 개발 전문가들도 도전을 받았습니다. 어떤 사람들은 10 만 명 이상의 JavaScript 코드 라인이 큰 것으로 간주되고 있으며, 어떤 사람들은 JavaScript 코드의 크기가 1MB 이상이어야한다고 말합니다. 실제로 코드의 양은 설치된 코드 수로 측정 할 수 없기 때문에 그 중 어느 것도 정확하지 않습니다. 많은 사소한 JS 코드는 10 만 라인을 쉽게 초과 할 수 있습니다.
"큰"에 대한 나의 정의는 다음과 같습니다. 정확하지는 않지만 비교적 가깝습니다.
저는 개인적으로 큰 JavaScript 프로그램이 매우 중요해야한다고 생각하며 헤비급 데이터를 처리하고 브라우저에 표시하려는 많은 뛰어난 개발자의 노력을 통합합니다.
현재 프로그램 아키텍처를 검토하십시오
이 문제가 얼마나 중요한지 강조 할 수 없습니다. 많은 숙련 된 개발자들은 종종 "기존의 창의적 및 디자인 패턴은 이전 중형 프로젝트에서 매우 잘 작동하므로 약간 더 큰 프로그램에서 다시 사용하는 것이 좋을 것입니다."특정 프로그램에서는 사실이지만 대규모 프로그램이기 때문에 일반적으로 깨지고주의를 기울여야 할 큰 우려가 있어야한다는 것을 잊지 마십시오. 오랫동안 실행 된 프로그램 아키텍처를 검토하는 데 시간이 걸리는 시간을 간략하게 설명합니다. 대부분의 경우, 현재 JavaScript 프로그램 아키텍처는 다음과 같아야합니다 (모든 사람이 종종 ASP.NET MVC라고 부르는 것이 아니라 JS 아키텍처입니다.
맞춤형 위젯
모델
보기
컨트롤러
템플릿
라이브러리/툴킷
응용 프로그램 코어.
또한 프로그램을 여러 모듈만으로 캡슐화하거나 다른 디자인 패턴을 사용할 수도 있지만,이 구조가 아키텍처를 완전히 나타내는 경우 잠재적 인 문제가있을 수 있습니다. 몇 가지 중요한 점을 살펴 보겠습니다.
1. 건축에서 몇 가지 물건을 꺼내서 즉시 재사용 할 수 있습니까?
다른 코드에 의존하지 않는 별도의 모듈이 있습니까? 독립적인가? 사용중인 코드베이스로 이동 한 다음 일부 모듈 모듈 코드를 선택하고 새 페이지에 올리면 즉시 사용할 수 있습니까? 원칙은 괜찮다고 말할 수 있습니다. 오랫동안 계획하는 것이 좋습니다. 회사가 이전에 많은 중요한 프로그램을 개발 한 경우 갑자기 어느 날 누군가 가이 프로젝트의 채팅 모듈이 좋다고 말했습니다. 꺼내서 다른 프로젝트에 넣으십시오. 코드를 수정하지 않고 사용할 수 있습니까?
2. 시스템은 다른 모듈에 의존해야합니까?
시스템의 모든 모듈이 단단히 결합되어 있습니까? 이 질문을 우려로 받아들이 기 전에 먼저 설명하겠습니다. 모든 모듈에 종속성이 없어야하는 것은 아닙니다. 예를 들어, 세분화 된 함수는 기본 함수에서 확장 될 수 있습니다. 내 문제는이 상황과 다릅니다. 다른 기능 모듈 이전의 종속성에 대해 이야기하고 있습니다. 이론적으로, 모든 다른 기능 모듈에는 종속성이 너무 많아서는 안됩니다.
3. 프로그램의 한 부분에 문제가 발생하면 다른 부분이 여전히 작동합니까?
Gmail과 유사한 프로그램을 구축하면 Gmail의 많은 모듈이 페이지를 초기화 할 때로드되지 않은 채팅 채팅 모듈과 같이 동적으로로드되며로드 후 오류가 발생하더라도 페이지의 다른 부분이 정상적으로 사용할 수 있음을 알 수 있습니다.
4. 모듈을 매우 간단한 방법으로 테스트 할 수 있습니까?
각 모듈은 수백만 명의 사용자가있는 대형 사이트 또는 여러 사이트에서도 사용하여 사용될 수 있으므로 모듈은 테스트를 견딜 수 있어야합니다. 즉, 아키텍처 내부 또는 외부에 관계없이 다양한 환경에서 전달할 수있는 대부분의 주장을 포함하여 매우 간단하게 테스트 할 수 있어야합니다.
장기 고려
큰 프로그램을 구성 할 때 가장 중요한 것은 미래 지향하는 것입니다. 한 달 또는 1 년 후에 상황을 고려할 수는 없습니다. 더 오랜 시간 동안 변화의 가능성을 고려해야합니까? 개발자는 종종 DOM 운영 코드와 프로그램을 너무 단단히 바인딩하지만 때로는 별도의 논리를 다른 모듈로 캡슐화했습니다. 왜 그것이 장기적으로 좋지 않은지 생각해보십시오.
내 동료는 한 번은 정확한 아키텍처가 미래의 시나리오에 적합하지 않을 수 있으며 때로는 맞습니다. 그러나 그렇게해야 할 때 많은 돈을 지불 할 것입니다. 예를 들어 특정 성능, 보안 및 설계 이유에 대해 Dojo, JQuery, Zepto 및 Yui를 교체하도록 선택해야 할 수도 있습니다. 현재 문제가 있습니다. 대부분의 모듈에는 돈, 시간 및 사람이 필요한 종속성이 있습니다.
일부 작은 사이트에서는 괜찮지 만 큰 사이트는 다양한 모듈 사이의 다양한 문제에 대해 걱정하지 않고보다 유연한 메커니즘을 제공해야합니다. 이것은 돈과 시간을 절약합니다.
요약하면, 이제 전체 프로그램을 다시 작성하지 않고 일부 클래스 라이브러리를 교체 할 수 있습니까? 그렇지 않다면, 우리가 아래에 대해 이야기 할 것이 당신에게 더 적합합니다.
많은 숙련 된 JavaScript 개발자가 몇 가지 주요 메모를했습니다.
JavaScriptMVC의 저자 인 Justin Meyer는 다음과 같이 말했습니다.
큰 프로그램을 구축하는 데있어 가장 큰 비결은 대규모 프로그램을 구축하지 않지만 프로그램을 작은 모듈로 나누기, 각 작은 모듈을 테스트 가능하고 상당한 규모로 만들고 프로그램에 통합한다는 것입니다.
고성능 JavaScript 웹 사이트 저자 Nicholas, Zakas :
"핵심은 처음부터 이것이 어떻게 성장할 것인지 전혀 알지 못한다는 것을 인정하는 것입니다. 모든 것을 알지 못한다는 것을 받아들이면 시스템을 방어 적으로 설계하기 시작합니다. 변경 될 수있는 주요 영역을 식별합니다. 예를 들어 약간의 시간을 넣을 때 매우 쉬운 종종 매우 쉽습니다. 다른 시스템과 통신하는 앱의 모든 부분이 변경 될 가능성이 높아야합니다." -
많은 텍스트 문제가 너무 귀찮습니다. 요약하면, 모든 것이 변경 될 수 있으므로 추상적이어야합니다.
JQuery Fundamentals 저자 Rebecca Murphey :
각 모듈 간의 연결이 가까울수록 재사용 가능성이 떨어지고 변경의 어려움이 커집니다.
위의 중요한 견해는 아키텍처 구축의 핵심 요소이며 항상 기억해야합니다.
영감
브레인 스토밍합시다. 모듈, 각 모듈 및 프로그램 통신 간의 종속성이없는 느슨하게 결합 된 아키텍처가 필요하며, 중간 계층이 해당 메시지를 인수하고 처리합니다.
예를 들어, 온라인 베이커리 프로그램을 구축하는 JavaScript가있는 경우 모듈은 "전달해야 할 42 라운드가 있습니다"라는 메시지를 보냅니다. 우리는 다른 레이어 레이어를 사용하여 모듈에서 보낸 메시지를 처리하고 다음을 수행합니다.
모듈은 프로그램 코어에 직접 액세스하지 않습니다
모듈은 직접 호출하거나 다른 모듈에 영향을 미치지 않습니다
이렇게하면 특정 모듈의 오류로 인해 모든 모듈에서 오류가 발생하지 않습니다.
또 다른 문제는 보안입니다. 실제 상황은 대부분의 사람들이 내부 보안이 문제라고 생각하지 않는다는 것입니다. 우리는 프로그램이 혼자서 구축된다고 마음 속에 말합니다. 나는 어느 것이 공개적이고 사적인지 알고 있습니다. 보안에 문제가 없지만 프로그램 코어에 액세스하기 위해 어떤 모듈을 정의 할 수 있습니까? 예를 들어, 관리자 모듈을 호출하지 않기를 원하지 않는 채팅 채팅 모듈이 있거나 DB 쓰기 권한이있는 모듈을 호출하지 않기를 원합니다. 이들 사이에 취약성이 있고 XSS 공격을 쉽게 일으킬 수 있기 때문입니다. 각 모듈은 모든 것을 수행 할 수 없지만 대부분의 아키텍처의 JavaScript 코드에는 현재이 문제가 있습니다. 권한 부품에 액세스 할 수있는 모듈을 제어 할 수있는 중간 계층을 제공합니다. 즉, 모듈은 우리가 승인 한 부품의 대부분 만 달성 할 수 있습니다.
제안 된 건축
우리의 기사의 초점은 이번에 우리가 제안하는 아키텍처가 우리 모두가 잘 알려진 디자인 패턴을 사용한다는 것입니다 : 모듈, 정면 및 중재자.
기존 모델과 달리 각 모듈을 분리하기 위해 모듈에서 일부 이벤트 이벤트 만 게시 할 수 있습니다. 중재자 모드는 이러한 모듈의 메시지 메시지를 구독 한 다음 알림 응답을 제어 할 수 있습니다. 정면 모드 사용자는 각 모듈의 권한을 제한합니다.
다음은주의를 기울여야 할 부분입니다.
1 디자인 패턴
1.1 모듈 이론
1.1.1 개요
1.1.2 모듈 모드
1.1.3 객체 자체 면적 크기
1.1.4 CommonJS 모듈
1.2 외관 모드
1.3 중재자 모드
2 아키텍처에 적용하십시오
2.1 외관 - 핵심 추상화
2.2 중재자 - 프로그램 코어
2.3 긴밀하게 협력하십시오
모달 이론
모든 사람이 모듈 식 코드를 어느 정도 사용했을 수 있습니다. 이 모듈은 완전하고 강력한 프로그램 아키텍처의 일부입니다. 각 모듈은 별도의 목적을 위해 생성됩니다. Gmail로 돌아가서 예를 들어 봅시다. 채팅 채팅 모듈은 별도의 부분 인 것처럼 보이지만 실제로는 별도의 하위 모듈이 많이 있습니다. 예를 들어, 내부의 표현 모듈은 실제로 별도의 하위 모듈로, 이메일을 보내는데도 창에서 사용됩니다.
다른 하나는 모듈을로드, 삭제 및 동적으로 교체 할 수 있다는 것입니다.
JavaScript에는 모듈을 구현하는 몇 가지 방법이 있습니다. 모든 사람은 모듈 패턴과 객체 리터럴에 익숙합니다. 이미 이것에 익숙하다면이 섹션을 무시하고 CommonJS 부분으로 직접 이동하십시오.
모듈 모드
모듈 패턴은 비교적 인기있는 설계 패턴입니다. 버팀대를 통해 개인 변수, 방법 및 상태를 캡슐화 할 수 있습니다. 이러한 내용을 감싸면 일반적으로 글로벌 객체에 직접 액세스 할 수 없습니다. 이 설계 패턴에서는 하나의 API 만 반환되고 다른 모든 내용은 비공개로 캡슐화됩니다.
또한이 패턴은 자체 실행 된 기능 표현과 유사합니다. 유일한 차이점은 모듈이 객체를 반환하고 자체 실행 된 함수 표현식은 함수를 반환한다는 것입니다.
우리 모두 알다시피, JavaScript는 다른 언어에 액세스 수정자가되기를 원하지 않으며 각 필드 또는 방법에 대해 개인 및 공개 수정자를 선언 할 수 없습니다. 그렇다면이 패턴을 어떻게 구현합니까? 그것은 내부 객체를 호출 할 수있는 일부 공개 방법을 포함하여 객체를 반환하는 것입니다.
아래 코드를 살펴보십시오. 이 코드는 자체 실행 코드입니다. 선언에는 글로벌 객체 Batterymodule이 포함됩니다. 바스켓 어레이는 개인이므로 전체 프로그램 이이 개인 배열에 액세스 할 수 없습니다. 동시에, 우리는 3 가지 방법 (예 : additem, getitemcount, gettotal)을 포함하는 객체를 반환합니다. 이 3 가지 방법은 개인 바스켓 어레이에 액세스 할 수 있습니다.
var basketmodule = (function () {var basket = []; // privatereturn {// public additem : function (values) {verse.push (vales);}, getItemCount : getItemCount : return basket.length;}, getTotal : function () {var q = this. this.TI (), p = 0; } return p;}}} ());또한 우리가 반환하는 객체는 바스켓 모듈에 직접 할당되므로 다음과 같이 사용할 수 있습니다.
// BasketModule은 MethodsBasketModule.additem ({item : 'bread', price : 0.5})이 될 수있는 속성이있는 객체입니다. console.log (basketModule.getItemCount ()); console.log (basketModule.getTotal ()); // 그러나 다음은 작동하지 않습니다 : console.log (basketModule.basket); // (반환 된 객체 내부에 정의되지 않은) console.log (basket); // (폐쇄 범위 내에서만 존재합니다)그렇다면 다양한 인기있는 클래스 라이브러리 (예 : Dojo, JQuery)에서 어떻게합니까?
도조
Dojo는 Dojo.Declare를 사용하여 클래스 스타일 선언 방법을 제공하려고 시도합니다. 모듈 패턴을 구현하는 데 사용할 수 있습니다. 예를 들어, 상점 네임 스페이스에서 바스켓 객체를 선언하려면 다음을 수행 할 수 있습니다.
// 전통적인 WayVar Store = Window.store || {}; store.basket = store.basket || {}; // dojo.setObjectdojo.setObject 사용dojo.provide와 결합하면 매우 강력합니다.
유아
다음 코드는 Yui의 원래 구현입니다.
yahoo.store.basket = function () {// "private"변수 : var myPrivateVar = "나는 yahoo.store.basket 내에서만 액세스 할 수 있습니다."; // "private"메소드 : var myPrivatemethod = function () {yahoo.log ( "나는 yahoo.store.basket 내에서만 액세스 할 수 있습니다"); } return {myPublicProperty : "나는 공공 재산입니다.", myPublicMethod : function () {yahoo.log ( "나는 공개 방법입니다."); // 바스켓 내에서 "개인"대표 및 메소드에 액세스 할 수 있습니다 : yahoo.log (myPrivateVar); yahoo.log (myprivatemethod ()); // myPublicMethod의 기본 범위는 저장소이므로 // "this"를 사용하여 공개 멤버에 액세스 할 수 있습니다 : yahoo.log (this.mypublicproperty); }};} ();jQuery
jQuery에는 모듈 패턴의 많은 구현이 있습니다. 다른 예를 살펴 보겠습니다. 라이브러리 함수는 새 라이브러리를 선언합니다. 그런 다음 라이브러리를 만들 때 init 메소드가 Document.ready에서 자동으로 실행됩니다.
함수 라이브러리 (module) {$ (function () {if (module.init) {module.init ();}}); return module;} var mylibrary = library (function () {return {init : function () { /*구현* /}};} ());객체 자체 얼굴 크기
객체 자체 면적 측정은 버팀대로 선언되며,이를 사용할 때는 새로운 키워드가 필요하지 않습니다. 모듈의 속성 필드의 공개/개인에 대해 크게 신경 쓰지 않으면이 메소드를 사용할 수 있지만이 메소드는 JSON과 다릅니다. 객체 자체 면적 크기 : var 항목 = {이름 : "tom", value : 123} json : var item = { "name": "tom", "value": 123}.
var myModule = {myProperty : 'somevalue', // 객체 리터럴에는 속성과 메소드가 포함될 수 있습니다. // 여기, 다른 객체는 구성에 대해 정의됩니다. // 목적 : myConfig : {UseCaching : true, language : 'en'}, // 매우 기본적인 메소드 MyMethod : function () {console.log ( 'I can Haz functionality?'); }, // 현재 구성을 기반으로 값을 출력합니다 MyMethod2 : function () {Console.log ( '캐싱은' + (this.myconfig.usecaching) : 'disabled'); . Console.log (this.myconfig.language); }}}; myModule.mymethod (); // Haz functionalitymymodule.mymethod2 (); // outputs enabledMymodule.mymethod3 ({language : 'fr', usecaching : false}); //정말로commonjs
나는 여기에 commonjs의 소개에 대해 이야기하지 않을 것입니다. 많은 기사가 이전에 소개했습니다. 여기서 언급하고 싶은 것은 CommonJS 표준에 두 가지 중요한 매개 변수가 수출되며 필요하다는 것입니다. 내보내기는로드 될 모듈을 나타내며,이로드 된 모듈은 다른 모듈에 의존해야하며로드해야합니다.
/*표준 CommonJS 모듈 형식 주위에 보일러 플레이트를 넣어 AMD 및 표준 CommonJS와 호환성을 달성하는 예 :*/(function (define) {define (function (요구, 내보내기) {// 모듈 내용 var dep1 = 요구 사항 ( "dep1"); Exports.somePortedEdfunction = function ()};});});}); define == "function"? define : function (factory) {factory (요구, 내보내기)});많은 CommonJS 표준 모듈로드 구현이 있습니다. 내가 선호하는 것은 요구 사항입니다. 모듈과 관련 종속성 모듈을 잘로드 할 수 있습니까? 간단한 예를 들어 봅시다. 예를 들어, 이미지를 ASCII 코드로 변환 해야하는 경우 먼저 인코더 모듈을로드 한 다음 EncodetoASCII 메소드를 얻습니다. 이론적으로 코드는 다음과 같습니다.
var encodetoascii = require ( "encoder"). encodetoascii; exports.encodesomesource = function () {// 다른 작업 후에 encodetoascii}를 호출하십시오.그러나 encodetoascii 함수가 창 객체에 첨부하는 데 사용되지 않으므로 위의 코드는 작동하지 않으므로 사용할 수 없습니다. 이것이 코드의 개선이 필요한 일입니다.
define (함수 (요구, 내보내기, 모듈) {var encodetoascii = require ( "encoder"). encodetoascii; exports.encodesomesource = function () {// 프로세스 encodetoascii}});CommonJS는 큰 잠재력을 가지고 있지만 삼촌은 그다지 익숙하지 않기 때문에 많이 소개하지 않을 것입니다.
외관 모드
외관 모델은이 모델의 아키텍처에서 중요한 역할을합니다. 많은 JavaScript 클래스 라이브러리 또는 프레임 워크 가이 모델에 반영됩니다. 가장 큰 기능은 높은 수준의 API를 포함하여 특정 구현을 숨기는 것입니다. 이는 인터페이스 만 노출되며 내부 구현의 결정을 직접 결정할 수 있음을 의미합니다. 이는 내부 구현 코드를 쉽게 수정하고 업데이트 할 수 있음을 의미합니다. 예를 들어, 오늘은 jQuery를 사용하여 구현하고 내일은 YUI를 변경하려고합니다. 이는 매우 편리합니다.
다음 예에서는 많은 개인 방법을 제공 한 다음 간단한 API를 노출하여 외부 세계가 내부 방법을 실행하고 호출 할 수 있도록 간단한 API를 노출시킵니다.
var module = (function () {var _private = {i : 5, get : function () {console.log ( 'current value :' + this.i);}, set : function (val) {this.i = val;}, run : function () {console.log ( 'running'); {console.log () {j 함수 (args.run) {_private.get ();Facade와 우리가 말하는 것의 차이점은 Facade가 기존 기능 만 제공하는 반면 중재자는 새로운 기능을 추가 할 수 있다는 것입니다.
중재자 모드
Modiator에 대해 이야기하기 전에 먼저 예를 들어 봅시다. 전설적인 타워 인 공항 비행 제어 시스템은 절대적인 힘을 가지고 있습니다. 항공기의 이륙 및 상륙 시간과 장소를 제어 할 수 있습니다. 항공기와 항공기는 이전에 통신 할 수 없으므로 탑은 공항의 핵심이며 중재자는이 타워와 동일합니다.
중재자는 프로그램에 여러 모듈을 갖는 데 사용되며 각 모듈에 종속성을 갖기를 원하지 않으면 중재자 모드는 중앙 집중식 제어의 목적을 달성 할 수 있습니다. 실제 시나리오에서, 중재자는 원하지 않는 많은 모듈을 캡슐화하여 중재자를 통해 연결하고 느슨하게 결합하여 중재자를 통해 통신해야합니다.
그렇다면 중재자 모드의 장점은 무엇입니까? 그것은 디커플링입니다. 이전에 관찰자 패턴을 잘 이해하고 있다면 아래 중재자 다이어그램을 이해하는 것은 비교적 간단합니다. 다음 그림은 높은 수준의 중재자 패턴 다이어그램입니다.
생각해보십시오. 각 모듈은 게시자이며 중재자는 게시자이자 가입자입니다.
모듈 1은 중재자에게 실제 일을 방송하여 무언가를해야한다고 말합니다.
중재자가 메시지를 캡처 한 후 메시지를 처리하는 데 사용해야하는 모듈 2를 즉시 시작하십시오. 모듈 2 처리가 완료된 후에는 정보를 중재자에게 반환하십시오.
동시에, 중재자는 모듈 3을 시작하고 모듈 2의 리턴 메시지를 수신 할 때 모듈 3에 자동으로 로그인합니다.
모듈 사이에 통신이 없음을 알 수 있습니다. 또한 중재자는 각 모듈의 상태를 모니터링하는 기능을 구현할 수도 있습니다. 예를 들어, 모듈 3에 오류가 있으면 중재자는 일시적으로 다른 모듈 만 원한 다음 모듈 3을 다시 시작한 다음 계속 실행할 수 있습니다.
되돌아 보면, 중재자의 장점은 느슨하게 결합 된 모듈이 동일한 중재자에 의해 제어된다는 것을 알 수 있습니다. 이 모듈은 이벤트를 방송하고 듣기 만하면되며 모듈간에 직접 연결할 필요가 없습니다. 또한 한 번에 정보를 처리하는 데 여러 모듈을 사용하여 향후 기존 제어 로직에 새 모듈을 추가 할 수 있습니다.
모든 모듈이 직접 통신 할 수 없으므로 상대적으로 성능이 약간 감소 할 수 있지만 그만한 가치가 있다고 생각합니다.
위의 설명을 기반으로 간단한 데모를 사용해 봅시다.
var mediator = (function () {var subscribe = function (channel, fn) {if (! mediator.channels [channel]) 중개자 중개자 [채널] = []; 중재자 channels [channel] .push ({context : context : context : fn}); return (return = return)) {rach arr. array.slice.call (var i = 0, l = 중재자) {var subscription. 구독 : installto : function (obj) {OBJ.Publish =} ();그런 다음 2 개의 모듈이 있습니다.
// 중앙 집중식 중재자 중재자의 pub/sub. Mediator.publish ( 'Namechange', 'David'); // Tim, David // 제 3 자 중재자를 통한 Pub/Sub var obj = {이름 : 'sam'}; mediator.installto (obj); obj.subscribe ( 'namechange', function (arg) {console.log (this.name); this.name = arg; console.log (this.name); obj.publish ( 'Namechange', 'John'); // 샘, 존응용 프로그램 외관 : 응용 프로그램의 핵심 추상화
외관은 응용 프로그램 코어의 초록으로 작동하며 중재자와 모듈 간의 통신을 담당합니다. 각 모듈은이 외관을 통해서만 프로그램 코어와 통신 할 수 있습니다. 초록으로서의 책임은 이러한 모듈에 언제든지 일관된 인터페이스를 제공 할 수 있도록하는 것입니다. 모든 모듈 구성 요소는이를 통해 중재자와 통신하므로 정면은 신뢰할 수 있고 신뢰할 수 있어야합니다. 동시에, 모듈에 대한 인터페이스를 제공하는 함수로서, Facade는 다른 역할, 즉 보안 제어, 즉 프로그램의 어느 부분에 액세스 할 수 있는지 결정해야합니다. 모듈 구성 요소는 자체 방법 만 호출 할 수 있으며 무단 컨텐츠에 액세스 할 수 없습니다. 예를 들어, 모듈은 DataValidationCompletedWritEtoDB를 방송 할 수 있습니다. 보안 검사는 모듈에 데이터베이스에 쓰기 권한이 있는지 확인해야합니다.
요컨대, 중재자는 외관 승인 감지 후에 만 정보 처리 만 수행 할 수 있습니다.
응용 프로그램 중재자 : 응용 프로그램의 핵심
중재자는 응용 프로그램의 핵심 역할로 작동하며 그의 책임에 대해 간단히 이야기합시다. 가장 핵심적인 작업은 모듈의 수명주기를 관리하는 것입니다. 이 코어가 모든 정보를 캡처하면 프로그램이 처리 방법, 즉 시작 또는 중지 할 모듈을 결정해야합니다. 모듈이 시작되면 애플리케이션 코어없이 자동으로 실행할 수 있어야합니다. 예를 들어 DOM이 준비되었을 때 실행 해야하는지 여부를 결정해야하므로 모듈 자체가 결정해야합니다.
어떤 상황에서 모듈이 중지됩니까? 프로그램이 모듈에 실패하거나 오류가 발생 함을 감지하면 프로그램은 사용자 경험을 향상시키는 주요 목적으로 구성 요소를 다시 시작할 수 있도록 모듈의 메소드가 계속 실행되는 것을 방지하기로 결정해야합니다.
또한 코어는 다른 기능에 영향을 미치지 않고 모듈을 동적으로 추가하거나 삭제할 수 있어야합니다. 일반적인 예는 페이지로드 시작시 모듈을 사용할 수 없지만 사용자가 작동 한 후에는 모듈을 동적으로로드 한 다음 실행해야합니다. Gmail의 채팅 기능과 마찬가지로 성능 최적화 목적으로 이해하기 쉽습니다.
예외 오류 처리는 Application Core에서 처리합니다. 또한 각 모듈은 정보를 방송 할 때 Core에 오류를 방송하여 프로그램 코어가 상황에 따라 이러한 모듈을 중지/다시 시작할 수 있도록합니다. 이것은 또한 느슨하게 결합 된 아키텍처의 매우 중요한 부분입니다. 모듈을 수동으로 변경할 필요가 없습니다. 중재자를 통해 게시/구독을 사용하여이를 수행 할 수 있습니다.
모으다
각 모듈에는 프로그램에 다양한 기능이 포함되어 있습니다. 처리 할 정보가 있으면 프로그램에 알리는 정보를 발급합니다 (이것은 주요 책임입니다). 다음 QA 섹션에서는 모듈이 일부 DOM 도구 작동 방법에 의존 할 수 있지만 시스템의 다른 모듈에 의존해서는 안된다고 언급했습니다. 모듈은 다음 내용에주의를 기울이지 않아야합니다.
1.이 모듈에서 게시 한 정보를 구독하는 개체 또는 모듈
2.이 객체 클라이언트 또는 서버 측 개체입니다
3. 귀하의 정보에 가입 한 개체 수
Facade 추상화 응용 프로그램의 핵심은 모듈 간의 직접적인 통신을 피합니다. 각 모듈의 정보를 가입하고 승인 감지를 담당하여 각 모듈에 자체 별도의 승인을 받도록합니다.
Mediator (Application Core)는 중재자 모드를 사용하여 Module Management 및 시작/정지 모듈 실행을 담당하는 Publish/Subscribe Manager의 역할을 수행하며 오류로 모듈을 동적으로로드 및 다시 시작할 수 있습니다.
이 아키텍처의 결과는 모듈간에 의존성이 없다는 것입니다. 느슨하게 결합 된 응용 프로그램으로 인해 쉽게 테스트하고 유지 관리 할 수 있으며, 각 모듈은 다른 프로젝트에서 쉽게 재사용 할 수 있거나 프로그램에 영향을 미치지 않으면 서 동적으로 추가 및 삭제할 수 있습니다.
Pub/Sub Extension 게시 : 자동 이벤트 등록
이벤트의 자동 등록과 관련하여 특정 명명 사양을 따라야합니다. 예를 들어, 모듈이 MessageUpDate라는 이벤트를 게시하면 MessageUpDate 메소드가있는 모든 모듈이 자동으로 실행됩니다. 이점과 장점과 단점이 있습니다. 특정 구현 방법의 경우, 다른 게시물을 볼 수 있습니다 : jQuery Custom Binding의 Magic 업그레이드 버전.
QA
1. Facade 또는 이와 유사한 샌드 박스 모드를 사용하지 않을 수 있습니까?
아키텍처의 개요는 Facade가 승인 확인 기능을 구현할 수 있다고 제안하지만 실제로 중재자가이를 수행 할 수있는 것은 전적으로 가능합니다. 라이트 아키텍처가해야 할 일은 거의 동일합니다.
2. 모듈이 직접적으로 의존 할 수 없도록 개선했습니다. 그것은 타사 라이브러리 (예 : jQuery)에 의존 할 수 없다는 것을 의미합니까?
이것은 실제로 양면 문제입니다. 위에서 언급했듯이 모듈에는 일부 하위 모듈 또는 기본 DOM 작동 도구 클래스 등과 같은 기본 모듈이있을 수 있습니다.이 수준에서는 타사 라이브러리를 사용할 수 있지만 쉽게 교체 할 수 있는지 확인하십시오.
3. 나는이 아키텍처를 좋아 하고이 아키텍처 사용을 시작하고 싶습니다. 참조하는 데 사용할 수있는 코드 샘플이 있습니까?
참조를위한 코드 샘플을 만들 계획이지만 그 전에는 Andrew Burgees의 Post Writing Modular JavaScript를 참조 할 수 있습니다.
4. 모듈이 응용 프로그램 코어와 직접 통신 해야하는 경우 가능합니까?
기술적으로 모듈이 응용 프로그램 코어와 직접 통신 할 수없는 이유는 없지만 대부분의 애플리케이션 경험에서는 여전히 허용되지 않습니다. 이 아키텍처를 선택 했으므로 아키텍처에서 정의 된 규칙을 준수해야합니다.
감사의 말
원래 게시물에 대한 Nicholas Zakas 덕분에 아이디어를 함께 요약하고 Andree Hansson, 기술 검토를 위해 Andree Hansson, Rebecca Murphey, Justin Hann, John Hann, Peter Michaux, Paul Irish 및 Alex Sexton 에게이 세션과 관련된 많은 정보를 제공했습니다.