「ASP.NET SPA」を編集中 (節単位)

== 基本概念 ==
[[ファイル:ASP.NET SPA概念図.png]]
<br style='clear:both'/>

画像をみてわかるようにハッキリ言ってASP.NET SPAという名前だが、別に[[ASP.NET]]である必要性はない。
サーバーサイドは[[RESTful]]かつ[[JSON]]でクライアントと通信さえ出来れば何でもよいわけで、[[Ruby]]や[[PHP]]なんかを使ってもSingle Page Applicationは実現できる。SPAの開発者がASP.NETの中の人達なので[[インテリセンス]]のコメントの充実度や環境構築の手軽さ、デバッグの容易さなんかは[[Visual Studio]]が最先端だよ、[[MSDN]]入れよ、というお話。

=== サーバーサイド ===
==== [[ASP.NET MVC]] ====
[[ASP.NET MVC]]である必要性を感じないどころか、動的コンテンツどころか、静的コンテンツだけで何とかなってしまいそうなくらい。

==== [[ASP.NET Web API]] ====
これ重要。

=== クライアントサイド ===
==== [[jQuery]] ====
[[DOM]]による[[HTML]]の加工と、[[AJAX]]による通信の根幹を担うもっとも重要な部分。

==== [[upshot.js]] ====
[[MVVM]]、つまりウェブなのにリアルタイムで事あるごとにサーバーと通信しまくる鬼仕様という関係で、ASP.NET SPAでは[[jQuery]]と[[knockout.js]]の間に[[JavaScript]]で書かれたクライアントサイドのデータキャッシュ機構が搭載されている。

ASP.NET SPAモドキの独自SPAであれば、キャッシュなどという軟弱なシステムは導入せず、サーバーの増強で乗り切るのが漢。ただし電気の無駄として時代背景に反する諸刃の剣。

==== [[knockout.js]] ====
ASP.NET SPAの中でも特に重要な[[MVVM]]を担う部分。

==== [[history.js]]と[[nav.js]] ====
ここまで見てわかるようにASP.NET SPAは大半がクライアントサイド、つまり[[ウェブブラウザ]]で動くわけだが、間違ってリロードや戻るボタンを押すと悲しいことになるのがクライアントサイドの通例。それをクライアントサイドでセッションのようなものを実現し、回避してくれる神ライブラリ層がこれ。あるとないとでは何よりデバッグの捗り具合が桁違い。

ASP.NET SPAであれば純正を使うべきだが、独自SPAであれば[[sammy.js]]を使って似たようなことはできる。
というか[[ASP.NET MVC 3]]上でASP.NET SPAモドキを作っているとsammy.jsでもなんとかなっている。