そこで、JavaScript でも MVCパターンを適用し、モデルとビューの分離して、開発・保守しやすい設計にする、という流れになってきています。MVCは、元々は Smalltalk で GUI アプリを作るときの設計指針として考えられました。デザインパターンの一つでもありますが、Singleton や Observer といった GoFのデザインパターンよりも抽象度の高い、ソフトウェアアーキテクチャです。

そして時は流れ、Webの時代になると Strutsなどで代表されるWeb3層モデルとして、Webアプリの設計パターンとして一世を風靡しました。そして今、クライアントサイドのWebアプリへの適用として、再度GUI向けのMVCが脚光を浴びています。

Webの時代でもMVCパターンはWebだけに使われていたわけではありません。GUIアプリを作るためのMVCについて色々と議論が進んでいました。

モデルとビューを分離しコントローラーで制御するという古典的MVC、ドメインモデルにビューに関するロジックを埋め込んだプレゼンテーションモデルを使うPM（Presentation Model）、PMの派生でビューモデルをビューとデータバインドするMVVM（Model, View, ViewModel）、ビューでユーザの入力を受け、プレゼンタに渡し、プレゼンタがモデルを更新するMVP（Model, View, Presenter）など、様々な派生パターンがあります。（参考: 開発者が知っておくべき、6つのUIアーキテクチャ・パターン）

他にも大規模MVCを分割するパターンとして、階層的MVCとしてのRecursiveMVC、エージェントをいう塊にして他のエージェントと連携して階層をつくるPAC（Presentation, Control, Abstraction）などがあります。（参考: PACについてのまとめ http://hamamuratakuo.blog61.fc2.com/blog-entry-432.html）

こういったパターンを、JavaScriptで簡単に使えるようにしたフレームワークが沢山できています。Backbone.js、Spine.js、Ember.js、javascriptMVC、AngularJS、...etc。（参考: JavaScriptのMVCフレームワークと仲間たち）

これらは同じMVCパターンを実現しているのだけれど、それぞれの解釈で、それぞれ異なる使い方になっていることが非常に面白い。例えばコントローラーの責務についても、Backbone.js ではurlハッシュのルーティングを行うのが主目的で、Spine.js ではモデルのイベントをビューにバインドするもの、Ember.js はモデルをラップして操作する、といったようになっている。

なお、これらの色々なMVC フレームワークでTodoアプリを実装したサンプルが TodoMVC にあります。同じアプリを別のフレームワークで作るとどうなるか大変参考になります。

今後、クライアントサイドWebアプリがますます注目され、このような設計、フレームワークの重要性が増していくでしょう。MVC is dead なんて話が最近盛り上がりましたね。まだまだ良い設計パターンが出てくるでしょう。特に個人的に気になるのが、規模が大きくなったときに、どう設計するのが良いのか。ベストプラクティスが溜まることを期待しています。

2012-06-22

JavaScript の Array.forEach vs jQuery.each vs Ext.each

javascript

前回の JS ArrayのforEach, filter, map の速度を調べてみた。に引き続き、Sencha Touch の Ext.each や、iPhone, iPad でどうなのかを比較してみました。

結果はこちらに → forEach 速度比較: jQuery、Senchaのブラウザ毎の差異

Macでは遅かったネイティブ forEach がモバイルでは早い結果となりました。また、Mac Chrome では一番早かった Sencha は、モバイルではちょっと遅いですね。そんな中 jQuery は安定した速度です。

100万回ループでの結果ですので、通常ならそんな問題にならないレベルだと思いますが、パフォーマンスが厳しいときに参考になるかも。

2012-06-20

JS ArrayのforEach, filter, map の速度を調べてみた。

javascript

最近のモダンブラウザのJS実装には、Array#forEach や filter, map などがビルトインされている。

jQuery とかの each使うより、ネイティブ実装のほうが早そう。しかし forEach、filter、map の速度に違いがあるのかちょと気になったので実験してみた。

環境は Mac OS X 10.7.4, MacBook Air（Late 2010）

2012/06/22 追記: −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Sencha Touch, iPad等を追加しました → JavaScript の Array.forEach vs jQuery.each vs Ext.each

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

100万個の配列にたいして、forEach と filter、map を実行して速度を比較した。コールバックの中身は同じ。それを10回やって、平均取ったのが以下の表。

Google Chrome 19.0.1084.56

#	forEach	filter	map	jQuery
1	365	350	258	59
2	123	106	335	62
3	192	105	351	62
4	187	107	561	66
5	181	101	325	94
6	175	101	323	68
7	186	100	324	62
8	178	99	322	66
9	178	108	354	57
10	234	115	362	58

Safari 5.1.7 (7534.57.2)

#	forEach	filter	map	jQuery
1	53	52	60	42
2	52	47	63	62
3	56	48	204	47
4	53	48	79	71
5	64	48	63	115
6	52	46	59	49
7	64	46	62	43
8	52	45	59	42
9	51	44	59	46
10	62	47	187	55

Safari はえーーー！！

jQuery.each はえーーーー！！！

jQuery はどちらのブラウザも早いですね。ネイティブのほうが早いと思い込んでいたけど、Chrome のネイティブ forEach はだめですね。。初回 forEach はなぜか必ず遅くなります。Safari ではそんなことない。

forEach と filter の比較をしようと思っていたんだけど、jQuery.each が早すぎて、もうこれでいいじゃんという予想外の結果に。

ネイティブをも凌駕するとは jQuery 恐ろしい子･･･

#	forEach	filter	map	jQuery
1	365	350	258	59
2	123	106	335	62
3	192	105	351	62
4	187	107	561	66
5	181	101	325	94
6	175	101	323	68
7	186	100	324	62
8	178	99	322	66
9	178	108	354	57
10	234	115	362	58

#	forEach	filter	map	jQuery
1	365	350	258	59
2	123	106	335	62
3	192	105	351	62
4	187	107	561	66
5	181	101	325	94
6	175	101	323	68
7	186	100	324	62
8	178	99	322	66
9	178	108	354	57
10	234	115	362	58

#	forEach	filter	map	jQuery
1	365	350	258	59
2	123	106	335	62
3	192	105	351	62
4	187	107	561	66
5	181	101	325	94
6	175	101	323	68
7	186	100	324	62
8	178	99	322	66
9	178	108	354	57
10	234	115	362	58