ここしばらくASP.NET 2.0を眺めていました。振り返ってみると、以前にベンチャーさんと.NET開発したときは、Windows Formsだったので、ASP.NETでの開発は、ほぼ初体験でありました。
実は、個人的に以前まで抱いていた"ASP.NET感"が、随分と様変わりしてしまっています。この辺で一旦、所感をまとめておきます。なお、私の場合、比較対象は、J2EEとPHPがメインになることを前置きます。
結論から言うと、ASP.NETは予想以上に「コンセプトが不明瞭、または方向性が定まらない」プラットフォームってことです。要素的な例を以下に挙
げましょう。
(1) DataSetとDataReaderの使い分け
ADO.NETでDBアクセスする際は、大きく分けて「DataReaderを使う」か「DataSetを使う」の2パターンがあり、両者はデータ取り出し方、生存期間
などに全く異なる利用法を強いられます。
ざっくり言うと、JavaのResultSet的な扱い方ができるのはDataReader、DOA的なアプローチなのがDataSetです。
Webや雑誌によく掲載されるのはDataSet(型付)の方ですし、そっちが主流になっていくんでしょうけど、かなり使い方に癖があって、更にビジネスロジックでのデータ変換もとてもやりにくく、基本設計からDAO的な視点が考慮されたシステムでないと、結構厳しいですね。
そういうややこしい仕様のため、hibernateや、iBatisなどのO/Rマッパーの対応もかなり中途半端で、これらを業務で利用するには辛いレベルですね。
(2) トランザクション処理
DBアクセスを含めた複数の業務ロジックに渡るACIDトランザクション制御ができるのはうれしいのですけど、そのために、ServicedComponentを実装してCOM+登録するのは非常に面倒くさい。Webアプリケーションなのに、IISを経由せず、ダイレクトにWindowsに依存してしまうのもどうなんでしょう？
ASP.NET 2.0からは、TransactionScopeクラスが追加され、多少楽になりましたが、これを使うと、SqlConnectionをコンストラクトする場所に気を
使う必要が出てきて、業務ロジックからデータアクセスロジックを隠蔽するのが困難になるんじゃないかと心配です。
(3) post back、ユーザーコントロール、カスタムコントロール
言うまでもなく、これらがASP.NETの特徴であるわけですけど、やっぱり、WindowsFormsとの近似を変に意識していて、Web標準からは隔絶しちゃってる部分が多すぎる(++) さらに、WindowsFormsと同じ動作をするってわけでもない。ひどくどっち付かずで、実装自由度の低いプラットフォームですわね。
(4) AssemblyInfo.cs、Server.Transfer()
この辺は、プラットフォームの完成度・成熟度を疑うような話なんですけど、例えばASP.NET 2.0になって突然 AssemblyInfo.cs ファイルが消えました。同ファイルの機能を代替するものがないのか…
画面制御で、J2EEのforward()に当たるものが、ASP.NETではServer.Transfer()です。Webや雑誌にも好く出てきますね。しかし、このメソッドを実行すると、必ずThreadAbortExceptionが発生します。Response.Endが実行された後にまたレンダリングしようとして発生してるらしい。なんじゃそりゃ？Server.Transfer()ってそういうもんでしょ？
おまけにこの例外は、catchしても自動的に再throwされたりする、ワケわからない奴です。まぁ、再throwは、Thread.ResetAbort()で防止できるんですけど、例外発生ログ出力を抑制することはできません。
MSDNで調べると、Server.Transfer()の例外発生については「仕様」ですって…。いい加減にしてよ…。
しょうがないので、代わりに Server.Execute() を使うことにしました。なんだかなぁ…
他にもいっぱいありますが、今夜はこの辺で。ん〜〜、全然好いとこないですねぇ。
