JavaScript プログラム開発のための MVC モードの使用に関する簡単な説明

JavaScript プログラム開発のための MVC モードの使用に関する簡単な説明_javascript スキル

WBOY

リリース： 2016-05-16 15:32:47

オリジナル

1389 人が閲覧しました

フロントエンド開発がますます重視され、クライアントコードの割合が日に日に増加しているため、JavaScript開発にMVCパターンをどのように適用するかという問題が常に言及されているようですので、簡単にお話したいと思いますここでの私の見解について。

MVC パターンの基本的な考え方は、アプリケーションをモデル、ビュー、コントローラーの 3 つの部分にカプセル化することで結合を削減し、開発を簡素化することです。これを言うのは空虚です。例を見てみましょう:

<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」から選択した動物が Web ページに対して実行できることをエコーします。上記は、デザインパターンやプログラミングのアイデアを適用せずに書かれたコードです。ここで 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 などのリッチテキストエディターなど、いくつかの JavaScript コントロールを除いて、実際の B/S システムでは、JavaScript 開発のファクトリーパターンに従っている限り、多くのメリットが得られます。これは、フロントエンド開発とバックエンド開発の性質の違いによって引き起こされます。 ASP.net または JSP プロジェクトに MVC パターンを適用すると、SDK は多かれ少なかれ、ビューとコントローラーのコードを自動的に生成します。しかし JavaScript はどうでしょうか。JavaScript には便利な SDK さえありません。完成したフレームワークはたくさんありますが、最終的には開発量が大幅に増加します。

開発量に比べて厄介なのは効率の問題です。 3 つの層間の相互通信には追加のオーバーヘッドがかかります。サーバー側の場合、これらの通信によって生じるオーバーヘッドはほとんど無視できます。ただし、JavaScript のような比較的非効率な言語の場合、さらにいくつかの呼び出しとイベントリスニングを行うと、明らかにパフォーマンスが低下します。また、JavaScript のクロージャ機能により、誤ってメモリリークが発生する可能性があります。これは、鶏を盗んだのに米を失ったという本物のケースです。
したがって、JavaScript 開発では、学んだ学術知識を適用することよりも、適度な開発が重要である可能性があります。結局のところ、フロントエンド開発はスキルを披露するためのものではなく、実践的な問題を解決することに基づいています。もちろん、Dflying gg には「リファクタリングはどこにでもある」という格言があります。自分のコードがますます煩雑になり、保守が難しくなっていると感じたら、MVC を使用してリファクタリングするかどうかを検討する必要があります。わかりました~

。

もう 1 つ: フロントエンド開発全体で MVC を使用する必要はなくなりましたか?いえいえ~実際、フロントエンド開発全体は大きなMVCアーキテクチャです—

モデル: HTML/XHTML の情報
ビュー: スタイルシート
コントローラー: EMAScript およびその他のスクリプト
これがウェブ標準の究極の目標ではないでしょうか....

したがって、JavaScript 開発では設計モデルを過剰に適用するよりも、フロントエンドコード全体の構造を把握することが常に重要です。

ただし、優れた MVC フレームワークもいくつかあります。シアトルのハッカー兼デザイナーである Gordon L. Hempton が、それらを比較してみます。

1. Backbone.js - 長所: 強力なコミュニティ、強力な勢い; 短所: 抽象化が弱く、多くの機能を緊急に追加する必要があります。
2. SproutCore - 長所: バインディングのサポート、信頼できるコミュニティ、多数の機能短所: 過剰な仕様、不要な機能からの分離が困難。
3. Sammy.js - 長所: 学習が容易で、既存のサーバーアプリケーションとの統合が容易ですが、短所: シンプルすぎて大規模なアプリケーションで使用できません。
4. Spine.js - 長所: 軽量、完全なドキュメント。短所: その中心概念である「Spine」は非同期ユーザーインターフェイスです。つまり、理想的にはユーザーインターフェイスがブロックされることはありませんが、この基盤には欠陥があります。。
5. Cappuccino - 長所: 大規模でよく考えられたフレームワーク、優れたコミュニティ、優れた継承モデル短所: 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—利点: 明確なコード、シンプルなバインディングおよび永続化メソッド、欠点: シングルトンコントローラーが使用されます。