2009년경부터 MVC는 점차 프론트엔드 분야에서 빛을 발했고 마침내 2015년 React Native의 출시로 큰 폭발을 일으켰습니다: AngularJS, EmberJS, Backbone, ReactJS, RiotJS, VueJS... .. 일련의 이름이 화려한 방식으로 나타나고 변화했으며, 그 중 일부는 점차 모든 사람의 시야에서 사라졌고 일부는 여전히 빠르게 성장하고 있으며 일부는 이미 특정 생태 환경에서 자신의 역할을 수행했습니다. 그러나 무슨 일이 있어도 MVC는 프런트 엔드 엔지니어의 사고 방식과 작업 방식에 깊은 영향을 미쳤으며 앞으로도 계속 그럴 것입니다.
MVC를 설명하는 많은 예는 Backbone의 컬렉션이나 AngularJS의 모델과 같은 특정 프레임워크의 특정 개념에서 시작됩니다. 하지만 프레임워크가 클래스 라이브러리(jQuery)나 도구 세트(Underscore)가 아닌 프레임워크인 이유는 그 뒤에는 뛰어난 디자인 개념과 모범 사례가 많이 있기 때문입니다. 이러한 디자인 본질은 서로 보완하고 서로 맞물려 있습니다. , 복잡한 프레임워크를 통해 짧은 시간 안에 특정 디자인 패턴의 본질을 보는 것은 쉽지 않습니다.
이것이 이 에세이의 유래입니다. 모든 사람이 개념을 이해할 수 있도록 돕기 위해 작성된 프로토타입 코드는 가능한 한 간단해야 하며, 모든 사람이 개념을 이해할 수 있을 만큼 단순해야 합니다.
1. MVC의 기본은 모델과 뷰의 동기화를 이루는 핵심인 관찰자 패턴입니다
단순화를 위해 각 모델 인스턴스에는 하나의 기본 값만 포함됩니다.
function Model(value) {
this._value = typeof value === 'undefined' ? '' : value;
this._listeners = [];
}
Model.prototype.set = function (value) {
var self = this;
self._value = value;
// model中的值改变时，应通知注册过的回调函数
// 按照Javascript事件处理的一般机制，我们异步地调用回调函数
// 如果觉得setTimeout影响性能，也可以采用requestAnimationFrame
setTimeout(function () {
self._listeners.forEach(function (listener) {
listener.call(self, value);
});
});
};
Model.prototype.watch = function (listener) {
// 注册监听的回调函数
this._listeners.push(listener);
};
// html代码：
<div id="div1"></div>
// 逻辑代码：
(function () {
var model = new Model();
var div1 = document.getElementById('div1');
model.watch(function (value) {
div1.innerHTML = value;
});
model.set('hello, this is a div');
})();관찰자 패턴의 도움으로 모델의 set 메소드를 호출하여 값을 변경하면 템플릿도 동기식으로 업데이트되지만 이 구현은 변경 사항을 수동으로 모니터링해야 하기 때문에 매우 어색하다는 것을 깨달았습니다. watch 메소드를 통해 모델 값을 전달하고 콜백 함수를 전달합니다. 뷰(하나 이상의 DOM 노드)를 모델에 더 쉽게 바인딩할 수 있는 방법이 있습니까?
2. 바인드 메소드를 구현하고 모델과 뷰를 바인드합니다
Model.prototype.bind = function (node) {
// 将watch的逻辑和通用的回调函数放到这里
this.watch(function (value) {
node.innerHTML = value;
});
};
// html代码：
<div id="div1"></div>
<div id="div2"></div>
// 逻辑代码：
(function () {
var model = new Model();
model.bind(document.getElementById('div1'));
model.bind(document.getElementById('div2'));
model.set('this is a div');
})();
간단한 캡슐화를 통해 뷰와 모델 간의 바인딩이 구체화되었습니다. 여러 뷰를 바인딩해야 하는 경우에도 쉽게 구현할 수 있습니다. 바인딩은 Function 클래스 프로토타입의 기본 메서드이지만 MVC와 밀접한 관련이 없습니다. 작성자는 바인딩이라는 단어를 정말 좋아하므로 여기서는 기본 메서드를 무시해도 됩니다. . 바인딩의 복잡성은 줄어들었지만 이 단계에서는 여전히 바인딩 논리를 비즈니스 코드에서 완전히 분리할 수 있습니까?
3. 로직 코드에서 바인딩을 분리하는 컨트롤러 구현
주의깊은 친구들은 우리가 MVC에 대해 이야기하고 있지만 위 기사에는 Model 클래스만 나타나는 것을 눈치챘을 것입니다. 결국 HTML은 이미 만들어진 View입니다. , 이 글에서도 처음부터 끝까지 HTML을 View로 사용하면 View 클래스가 자바스크립트 코드에 나타나지 않는데 왜 Controller 클래스가 보이지 않는 걸까요? 사실, 소위 "논리 코드"는 프레임워크 논리(이 기사의 프로토타입을 프레임워크라고 부르겠습니다)와 비즈니스 논리 사이에 높은 수준의 결합이 있는 코드 세그먼트이므로 걱정하지 마십시오.
바인딩 논리를 프레임워크에 맡기려면 바인딩을 완료하는 방법을 프레임워크에 알려야 합니다. JS에서는 주석을 완성하는 것이 어렵기 때문에 뷰에서 이 마크업 레이어를 수행할 수 있습니다. html의 태그 속성을 사용하는 것이 간단하고 효과적인 방법입니다.
function Controller(callback) {
var models = {};
// 找到所有有bind属性的元素
var views = document.querySelectorAll('[bind]');
// 将views处理为普通数组
views = Array.prototype.slice.call(views, 0);
views.forEach(function (view) {
var modelName = view.getAttribute('bind');
// 取出或新建该元素所绑定的model
models[modelName] = models[modelName] || new Model();
// 完成该元素和指定model的绑定
models[modelName].bind(view);
});
// 调用controller的具体逻辑，将models传入，方便业务处理
callback.call(this, models);
}
// html:
<div id="div1" bind="model1"></div>
<div id="div2" bind="model1"></div>
// 逻辑代码：
new Controller(function (models) {
var model1 = models.model1;
model1.set('this is a div');
});
그렇게 간단한가요? 그렇게 간단합니다. MVC의 본질은 컨트롤러에서 비즈니스 로직을 완성하고 모델을 수정하는 것입니다. 동시에 모델의 변경으로 인해 이러한 로직이 위의 코드에 반영되고 다중 뷰와 다중 모델을 지원합니다. 제작 프로젝트에서는 부족하지만 모든 분들의 MVC 학습에 조금이나마 도움이 되었으면 좋겠습니다.
주석이 제거된 정리된 "프레임워크" 코드:
function Model(value) {
this._value = typeof value === 'undefined' ? '' : value;
this._listeners = [];
}
Model.prototype.set = function (value) {
var self = this;
self._value = value;
setTimeout(function () {
self._listeners.forEach(function (listener) {
listener.call(self, value);
});
});
};
Model.prototype.watch = function (listener) {
this._listeners.push(listener);
};
Model.prototype.bind = function (node) {
this.watch(function (value) {
node.innerHTML = value;
});
};
function Controller(callback) {
var models = {};
var views = Array.prototype.slice.call(document.querySelectorAll('[bind]'), 0);
views.forEach(function (view) {
var modelName = view.getAttribute('bind');
models[modelName] = models[modelName] || new Model();
models[modelName].bind(view);
});
callback.call(this, models);
}후기:
Flux와 Redux를 배우는 과정에서 저자는 도구 사용법을 익혔지만 저는 그것만 알고 있을 뿐 왜 그런지는 항상 "Flux는 MVC를 피하고 단방향 데이터 흐름을 선호합니다"라고 강조했습니다. 나는 항상 단방향 데이터 흐름과 MVC가 충돌하지 않는다고 생각합니다. ReactJS 문서에는 왜 둘이 반대되는지 이해가 되지 않습니다. 그 사람이 없는 사람이다(피하다, 피하다). 마지막으로 MVC의 정의로 돌아가서 다시 공부하기로 마음먹었습니다. 비록 일상 업무에서 무심코 복사해서 붙여넣었지만, 그래도 가끔씩 단어를 씹어먹고 고집해야 겠죠? 이 방법은 이 문장을 이해하는 데 큰 도움이 되었습니다. 여기서 제 생각을 여러분과 공유할 수 있습니다. 제가 MVC의 단방향 데이터 흐름과 Flux가 유사하다고 느끼는 이유는 MVC와 관찰자 패턴 사이에 명확한 구분이 없기 때문일 수 있습니다. 관계로 인해 발생 - MVC는 관찰자 패턴을 기반으로 하며 플럭스도 마찬가지입니다. 따라서 이러한 유사성의 원인은 MVC 및 플럭스 자체가 아니라 관찰자 패턴입니다. 이러한 이해는 포섬의 원본 디자인 패턴 책에서도 확인됩니다. "옵저버 패턴의 첫 번째이자 아마도 가장 잘 알려진 예는 Smalltalk 환경의 사용자 인터페이스 프레임워크인 Smalltalk Model/View/Controller(MVC)에 나타납니다. [KP88 ]. MVC의 Model 클래스는 Subject 역할을 하고, View는 관찰자의 기본 클래스입니다.
독자들이 이러한 프로토타입 장난감을 계속해서 확장하는 데 관심이 있다면 다음 지침을 참조하세요.
완전한 프레임워크는 수많은 개선과 수정을 거쳐야 합니다. 아직은 시작 단계에 불과합니다. 모두가 열심히 노력하길 바랍니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
