よーするに今の職場からでは恐らくこんなブログサイトはフィルタリングされて見られやしないだろう事を良いことに書きたい放題愚痴をまき散らしてしまえというお話です^^。

単なる表示上の変化に過ぎないものまでポストバックで実現する

ポストバックというのは ASP.NET 用語で、よーするにフォーム操作で発生する POST 送信とそれに対するサーバーからの応答によって、同一ページ上でのユーザーとシステムとの対話を実現してしまおうというやり方のことです。これは問い合わせ内容に応じて結果表示を切り替える仕組みとして想定されているものですが、どうやら一般的な ASP.NET 開発者は DB への問い合わせが発生しないようなことにも平気でポストバックを使ってしまうようです…。

例えばラジオボタンの選択に応じて入力項目の表示が切り替わるような UI とか、クライアントサイドスクリプトで事足りるのにも係わらず、なぜか AutoPostback="true" とかにして、 SelectedIndexChanged イベントハンドラをわざわざ書いて、わざわざ POST が発生するような作りにしてしまう。マスターページを使ってると ID が変化しちゃうから… という声もありそうですが、 runat="server" にさえしなければ ID も変化しないわけで、だったら <div> なり <span> なりで包んで表示/非表示ぐらいは出来るだろうに (それはそれで微妙にダサイんですが…)。

何でもかんでも Page.Session に突っ込む

DB に対する問い合わせ結果を表にして表示するような UI は業務系の Web アプリでは多いですが、一般的な ASP.NET 開発者の中には DB から取得した問い合わせ結果の DataTable (配列の豪華版みたいなもん) をそのまんま Page.Session に突っ込んで、ユーザーがレコードを選択したときの値の突き合わせのために再利用しようとする人が多いみたいです。

ASP.NET では、セッションに紐付いた情報はデフォルトではプロセスのメモリに格納されるとあります (だからラウンドロビン構成にしても同一セッションでのアクセスは常に同一の Web サーバーによって処理されるわけですね)。上記のような実装を想定してセッション状態ストアプロバイダーとやらを独自に実装していたり、 Web サーバのメモリ容量を十分に確保していたりしているなら良いのですが、ちゃんとそこまで想定していらっさる開発者さんってどれくらいいらっさるんでしょうね…。

何でもかんでも View State に突っ込む

ユーザーコントロールを実装する場合、コントロールの表示状態を保持するために、関連する情報を View State と呼ばれる場所に格納しておくものなんだそうです。いや、本当に表示状態に関する情報 *だけ* をここに突っ込むんであれば良いのでしょうが、データグリッドの DataSource に突っ込むようなでかいデータをそのまま View State に放り込む人とかも結構居て、そのおかげで出力される HTML がすさまじいことになったりするケースもちらほら見かけるようです… あれは BASE64 かなんかでエンコードした文字列をそのまんま hidden に書き出しますからね…。

他にもいろいろと言いたいことはあったような気もしますが、よーするにまとめてしまうと、何でもかんでもブラックボックス化して取っつきやすさばかりを重視した開発ツールなんて、もう初学者の学習教材専用ということにしてしまって、プロの現場に持ち込むのは止めましょうよという話だったりするわけです。ぐんにゃり。