JavaScript 프로그램 개발_javascript 기술을 위한 MVC 모드 사용에 대한 간략한 토론

프론트엔드 개발의 중요성이 높아지고 클라이언트 코드의 비중이 나날이 증가함에 따라 자바스크립트 개발에서 MVC 패턴을 어떻게 적용할 것인지에 대한 질문이 늘 언급되는 것 같아서 간략하게 이야기를 해보고자 합니다. 내 견해에 대해.

MVC 패턴의 기본 아이디어는 애플리케이션을 모델, 뷰, 컨트롤러의 세 부분으로 캡슐화하여 결합을 줄이고 개발을 단순화하는 것입니다. 이렇게 말하면 공허합니다. 예를 들어보겠습니다.

<select id="selAnimal">
  <option value="cat">cat</option>
  <option value="fish">fish</option>
  <option value="bird">bird</option>
</select>
<p id="whatDoesThisAnimalDo"></p>

<script type="text/javascript">
document.getElementById('selAnimal').onchange = function() {
  var thisAnimalDoes;
  switch ( this.value ) {
    case 'cat':
      thisAnimalDoes = "cat meows";
      break;
    case 'fish':
      thisAnimalDoes = "fish swims";
      break;
    case 'bird':
      thisAnimalDoes = "bird flies";
      break;
    default:
      thisAnimalDoes = "wuff&#63;";
  }
  document.getElementById('whatDoesThisAnimalDo').innerHTML = thisAnimalDoes;
}
</script>

이 작은 프로그램은 드롭다운 메뉴 "selAnimal"에서 선택한 동물이 할 수 있는 작업을 웹페이지에 반영합니다. 위 내용은 어떠한 디자인 패턴이나 프로그래밍 아이디어도 적용하지 않고 작성한 코드입니다. 여기에 MVC 패턴을 적용한다면 코드는 어떤 모습일까요?

<select id="selAnimal">
  <option value="cat">cat</option>
  <option value="fish">fish</option>
  <option value="bird">bird</option>
</select>
<p id="whatDoesThisAnimalDo"></p>

<script type="text/javascript">
// whatDoesAnimalDo 就是一个controller
var whatDoesAnimalDo = {
  // 选择视图
  start: function() {
    this.view.start();
  },
  // 将用户的操作映射到模型的更新上
  set: function(animalName) {
    this.model.setAnimal(animalName);
  },
};
// whatDoesAnimalDo的数据model
whatDoesAnimalDo.model = {
  // animal的数据
  animalDictionary: {
    cat: "meows",
    fish: "swims",
    bird: "flies"
  },
  // 当前的animal，也就是这个application的状态
  currentAnimal: null,
  // 数据模型负责业务逻辑和数据存储
  setAnimal: function(animalName) {
    this.currentAnimal = this.animalDictionary[animalName] &#63; animalName : null;
    this.onchange();
  },
  // 并且通知视图更新显示
  onchange: function() {
    whatDoesAnimalDo.view.update();
  },
  // 还需要响应视图对当前状态的查询
  getAnimalAction: function() {
    return this.currentAnimal &#63; this.currentAnimal + " " + this.animalDictionary[this.currentAnimal] : "wuff&#63;";
  }
};
// whatDoesAnimalDo的视图
whatDoesAnimalDo.view = {
  // 用户输入触发onchange事件
  start: function() {
    document.getElementById('selAnimal').onchange = this.onchange;
  },
  // 该事件将用户请求发送给控制器
  onchange: function() {
    whatDoesAnimalDo.set(document.getElementById('selAnimal').value);
  },
  // 视图更新显示的方法，其中视图会向model查询当前的状态，并将其显示给用户
  update: function() {
    document.getElementById('whatDoesThisAnimalDo').innerHTML = whatDoesAnimalDo.model.getAnimalAction();
  }
};
whatDoesAnimalDo.start();
</script>

...갑자기 코드가 너무 과장됐네요....
——Odu는 아직 관찰자 모드를 구현하지 않았습니다...
정말 좋지 않습니다.

이것은 MVC 패턴에 대한 가장 큰 비판을 불러일으킵니다. 단순한 시스템에 MVC 패턴을 적용하면 구조가 복잡해지고 효율성이 떨어집니다.

따라서 어디에서나 클릭하여 편집할 수 있는 데이터 그리드/트리 컨트롤과 같은 몇 가지 자바스크립트 컨트롤이나 MVC 적용에 매우 적합한 사용자 정의 플러그인을 지원하는 FckEditor/tinyMCE와 같은 서식 있는 텍스트 편집기를 제외하면 대부분의 실제 B/S 시스템에서는 JavaScript 개발 시 팩토리 패턴을 따르는 한 많은 이점을 얻을 수 있습니다. 이는 프론트엔드 개발과 백엔드 개발의 성격이 다르기 때문에 발생합니다. ASP.net 또는 JSP 프로젝트에 MVC 패턴을 적용하면 SDK는 일부 뷰 및 컨트롤러 코드를 자동으로 생성합니다. 그러나 JavaScript는 어떻습니까? JavaScript에는 유용한 SDK조차 없습니다. 비록 성숙한 프레임워크가 많이 있지만 궁극적으로 개발 양이 크게 늘어날 것입니다.

개발량에 비해 더 문제가 되는 것은 효율성의 문제입니다. 세 계층 간의 상호 통신에는 추가 오버헤드가 발생합니다. 서버 측의 경우 이러한 통신으로 인한 오버헤드는 거의 무시할 수 있습니다. 그러나 자바스크립트와 같이 상대적으로 비효율적인 언어의 경우 몇 번의 호출과 이벤트 청취로 인해 분명히 성능이 저하됩니다. 게다가 자바스크립트의 클로저 기능 때문에 실수로 메모리 누수가 발생할 수도 있습니다. 치킨을 훔치고 밥을 잃은 실제 사례입니다...
따라서 JavaScript 개발에서는 배운 학문적 지식을 적용하는 것보다 적당한 개발이 더 중요할 수 있습니다. 결국 프론트엔드 개발은 실력을 뽐내기 위한 것이 아니라 실질적인 문제를 해결하는 데 기반을 두고 있기 때문입니다. 물론, Dflying gg에는 "리팩토링은 어디에나 있다"라는 말이 있습니다. 자신의 코드가 점점 더 지저분해지고 유지 관리가 더 어려워진다고 느끼면 MVC를 사용하여 리팩토링해야 하는지 고려해야 합니다~

한 가지 더: 전체 프런트엔드 개발에서 더 이상 MVC를 사용할 필요가 없나요? 아니아니~ 사실 프론트엔드 개발 전체가 거대한 MVC 아키텍처입니다.——

모델: HTML/XHTML의 정보
보기: 스타일시트
컨트롤러: EMAScript 및 기타 스크립트
이것이 바로 웹 표준의 궁극적인 목표가 아닐까....

그렇기 때문에 자바스크립트 개발에서는 디자인 모델을 과도하게 적용하는 것보다 프론트엔드 코드 전체의 구조를 파악하는 것이 항상 더 중요합니다!

그러나 몇 가지 뛰어난 MVC 프레임워크도 있습니다. 시애틀의 해커이자 디자이너인 Gordon L. Hempton이 이를 비교했습니다.

1. Backbone.js - 장점: 강력한 커뮤니티, 강력한 단점: 약한 추상화, 많은 기능을 긴급하게 추가해야 함.
2. SproutCore - 장점: 바인딩 지원, 안정적인 커뮤니티, 많은 기능 단점: 과도한 사양, 불필요한 기능과의 분리가 어렵습니다.
3. Sammy.js - 장점: 배우기 쉽고 기존 서버 애플리케이션과 통합하기가 더 쉽습니다. 단점: 대규모 애플리케이션에서 사용하기에는 너무 간단합니다.
4. Spine.js - 장점: 가볍고 완전한 문서화; 단점: 핵심 개념인 "spine"은 비동기식 사용자 인터페이스입니다. 즉, 이상적으로는 사용자 인터페이스가 차단되지 않으며 이 기반에는 결함이 있습니다. .
5. 카푸치노 - 장점: 세심하게 계획된 대규모 프레임워크, 훌륭한 커뮤니티, 훌륭한 상속 모델. 단점: iOS 개발자가 JavaScript를 사용하여 Objective-C를 시뮬레이션하여 만들었습니다.
6. Knockout.js - 장점: 바인딩 지원, 완전한 문서 및 튜토리얼, 단점: 빈약한 바인딩 구문, 통합된 보기 구성 요소 계층 구조 부족.
7. Javascript MVC - 장점: 신뢰할 수 있는 커뮤니티, 단점: 열악한 문자열 기반 상속 모델, 컨트롤러와 뷰 간의 관계가 너무 가깝고 바인딩이 부족합니다.
8. GWT(Google Web Toolkit) - 장점: 포괄적인 프레임워크, 우수한 커뮤니티, 신뢰할 수 있는 Java 기반 구성 요소 상속 모델 단점: 시간의 테스트를 견디지 ​​못할 수 있으며 Java가 클라이언트 측에 있습니다. 위의 추상화는 약간 어색합니다.
9. Google Closure——장점: 컴포넌트 기반 UI 구성 시스템이 매우 우수합니다. 단점: UI 바인딩 지원이 부족합니다.
10. Ember.js - 장점: 복합 뷰와 UI 바인딩이 포함된 매우 풍부한 템플릿 시스템 단점: 상대적으로 새롭고 문서가 충분하지 않습니다.
11. Angular.js - 장점: 템플릿 범위 및 컨트롤러 디자인을 잘 고려하고 종속성 주입 시스템을 갖추고 있으며 풍부한 UI 바인딩 구문을 지원합니다. 단점: 코드의 모듈성이 강하지 않고, 뷰의 모듈성이 충분하지 않습니다.
12. Batman.js——장점: 명확한 코드, 간단한 바인딩 및 지속성 방법, 단점: 싱글톤 컨트롤러가 사용됩니다.