日々の破片

_ 最近のおれの考えるWebアプリケーション

Insider.NETの連載が終わった。

ASP.NETによる軽量業務アプリ開発

全部で6回にまとめたが、最後の2回（能書き部分を入れると最後の3回分）が当然（まとめになるわけだし）一番の要点だ。

一昨年あたりから、単発のWebアプリケーション開発を何度かやっていたのだが、やるたびにどんどんシンプルになっていって、結局、余分なことをまったくやらずに、ASPXだけでASP.NETを使ってちゃちゃっと作るのが一番ではないかと考えている。

もちろん前提がいくつもあって、ごく少人数（できれば1人）の開発であるとか、クライアント側にいろいろ制約を付けられるであるとか（あるいは極端に制約があるクライアントである、逆のようだが結局は同じ意味だ）、Windowsモノリシック（RDBがSQL Serverで、.NET Framework 4（3.5で十分）以上を何も考えずに使えて、IISがある）とかで、開発も少人数ならその後のメンテナンスもほとんど手間をかけられないとか、そんなところが重要だったりする。

ASPXの何が良いかというと、スクリプト言語の開発と同じで、何がデプロイされているかは、そのサイトのディレクトリを漁ればわかるということで、何をばかなと思うかも知れないが、一度バイナリーにしてソースと別に管理すると、なぜだか正しくデプロイしたのだろうな？ というようなところで引っかかって来ることが稀にあって、障害時にはそれが稀であってもある以上はそういう可能性まで考慮しなければならず、厄介だったりする。（ということまで視野に入れているのだから、ASPXが全部合わせて128ファイルみたいな規模に適用することはあり得ないことになる）

元々、JSPやらASPがくずというのは、1997年前後に周知されたわけだが、その理由は開発者がソフトウェア構成というものに余りにも無頓着だったことと、JSPのコンパイルの遅さ、ASP用のコンポーネントがフリースレッディングモデルだったり、アパートメントスレッディングモデルのくせにスレッド競合を考慮していないものを使ったり、ADOにバグがあったりとか、JDBCが腐っていたりとか、技術そのものよりも、その適用の問題だったわけだ。

で、三層に分けるのがいろいろと都合が良かったので、そこら中が三層で組まれるようになって（ロバストネス分析のバウンダリー、エンティティ、コントロールがMVCパターンのV、M、Cにマッピングされてみたり（Web MVCには、Smalltalkのデザインパターンではなくロバストネス分析が大本にあるんじゃないかなぁという気がする）、それを忠実に再現してStrutsとかが生まれてみたり、ノードのレベルではWebブラウザー－Webアプリケーション－RDBになってみたり）、まあ3つというのは、精霊聖霊と父と子の組み合わせであったり人間が文殊菩薩に近づくための方便だったり、子豚の兄弟だったりきりが良い。

テトラスクロール (1985年)(R.バックミンスター・フラー)

（3といえばバックミンスター・フラー）

で、それをいかに半自動的にウィザードを使って構築するかというのが、Visual StudioのASP.NETアプローチになったりするのだが、愕然とするような実装を見たのが2010年頃だ。

iPhone用のWebアプリケーションの実装を検収していたら、ASP.NETにLabelを貼り付けて、そこにビハインドにあるVB.NETのコードで組み立てたStringのインスタンスを流し込んでいる。なんだこりゃ。

いきなりVisual Studioを起動して、Webアプリケーションを開発しようとプロジェクトを選択すればASPXが作られて、ビハインドのコードも作られる。あとはASPXから余分なものを取り外してLabelを張って、ひたすらコードで文字列を組み立ててTextプロパティに設定すれば完了、簡単。そりゃそうだが。

そんな厄介なことするくらいなら、単にASPXで良いじゃないかと思ったが、まずそういうVisual Studioのウィザードの使い方を見たのが引っかかった。特に、その実装というかコードそのものは悪くなかったのが引っかかった点だ。

それとは別にjQueryを使ってクライアント側のコードをいじくっているうちに、JavaScriptの使いやすさに開眼したというのがあった。無茶苦茶記述しやすいじゃん。ああそうか、関数が一級市民なプログラミング言語というのは本来こう記述すべきだったのだな、と得心した。

それから、Visual StudioがEclipseほどではないにしろ、動作が遅くなったというのにも引っかかった。遅さを感じる原因は、ヘルプが出て来ないことにある（途中から少しまともになったが、一時、あまりのヘルプの遅さに本気でVisual Studioを捨てるところまで行った。今でもヘルプ（Microsoft Help Viewer）の起動時の遅さとインデックス検索の遅さは耐え難いのであまり積極的にVisual Studioを使う気にはなれない）。

そうこうするうちに、JavaScriptが実用的な速度で動作するようになり、わりとどこでもHTML5が使えるようになってくると、jQueryのブラウザーの差異吸収の有難味がなくなってきた。document.getElementBy...を$と数ストロークで書けるのは楽だが、jQueryのAPIを覚えるよりもDOMのAPIを覚えるほうが良い（つまりDRYだ）。

Visual Studioのヘルプが遅くて使い物にならないので、.NET FrameworkのコアなクラスとAPI以外は調べる気にもならなくなって（コアなところは普通に覚えてしまうし、C#の言語仕様は仕様書を読むのでどうでも良い）くる。

しかも今やASP.NETのコンパイル（は元々速かったけど）にしてもJSPのコンパイルにしても、考慮する必要がないくらいに高速だ。

JavaScriptがそこそこの速度で動き、DOMのAPIが共通で利用できるようになって、ASP.NETのコンパイルが速くて、C#の記述力が異様に向上した結果（var宣言とラムダ式の導入が大きい。これによってJavaScriptに遜色ない記述力が得られている）、ちょっとしたWebアプリケーションなら、HTMLを1つ、あとはモデル相当のコードをASP.NETに記述してJSONを返すようにして、UIに関連するものはすべてJavaScriptで記述すれば良いじゃないかとなった。あとはRDBとしてSQL Serverを使えれば（容量が収まればExpress Editionで十二分なパフォーマンスが出る）、それだけで十分だ。

連載は無理くり行数を減らすようにコードを固めたところがあって、本来はもう少しファイルを分離したり、統一的に扱えるようにおれさまアドホックAPIを導入したりするところだ。で、そのあたりが4種類くらいのAPIを妙な方法でASPX内に組み込んだりしているのが難点だが、それでも相当まともなASP.NETのWebアプリケーションへの適用方法を示せたと思う。枯れた技術だけを利用して効果を上げるというのは大事なことだろう。

で、おそらく2010年代中半の時代精神というのがあって、向うがどう考えるかは知ったことではないが、以下にあげるものと通底するものがあるとおれは考える。

オブジェクト指向は禁止するべき

（まったく同意しないが、おれの連載でのプログラミングスタイルはまったくオブジェクト指向ではないから（ASP.NET直書きである以上単なるシングルメソッドだ）、結局は同じことのようだ）

B00LBPGFJS

（効果的な適用を考えながら基本的な技術のみを組み合わせてシステムを作るという点では通じるものがある）

マイクロサービス（microservices）とは何か

（おれの連載はまったくマイクロサービスのマの字も意識してないのだが、だがこれも根底で通じるものがあるように見える）

まだあったはずだが忘れた。