atsukanrockのブログ

Microsoft系技術を中心にぼちぼち更新します

「正直、ASP.NETとその周辺はどうなのよ」を読んで

やねうらお氏曰く

やねうらお氏が最近ASP.NETの仕事をされているとのことなので、氏のブログでASP.NETについて何か言及があるかと思っていたら、「正直、ASP.NETとその周辺はどうなのよ」とのことだ。
氏の意見は以下のとおり。

  • 良い点
  • 悪い点
    • Expression Web2が、有償なのにも関わらず完成度が低い
    • リファクタリングをaspxに反映できない
    • LINQ to Entitiesが利口でない
    • SqlDataSourceの設計がおかしい

私の意見

やねうらお氏の意見に、概ね賛成だ。氏の意見に対し、私の意見も付け加える。

生産性が高い

氏の意見に賛成だ。生産性が高いことに、私はASP.NETの最大の魅力を感じている。生産性が高い理由は、氏が指摘しているコンポーネント化の仕組みの完成度の高さである。それに加え、私はライブラリ作成が好きなので、この点がまず非常に嬉しい。
ただ、生産性を低下させているいくつかの欠点があることも事実だ。それらの欠点のうち、私の生産性を最も低下させているのは、デバッガの起動が遅いことだ。私はVisual Studio 2005でASP.NET 2.0の開発をしているが、デバッガの起動がとにかく遅い。そのせいで、デバッガが起動するまでの空き時間にネットサーフィンを始めて、結局デバッガが起動したことに気付かないことも多い*1Visual Studio開発チームには、この点の改善を最も希望する*2

Expression Web2の完成度が低い

私はExpression Web2を使ったことがない。しかし、aspx*3ファイルデザイナの完成度の低さであれば、私にもわかる。氏はExpression Web2について指摘されているが、Visual Studio 2005であっても完成度は低い。例えば以下のような欠点がある。

  • CSSの適用結果を、デザイナでは確認できない(ブラウザで実行して初めてわかる)
  • ドラッグ&ドロップでデザインすると
    • ソースに不要なスペースが挿入される
    • HeightやWidthプロパティが、px単位で指定される(CSSでデザインしたいのに)

その結果は私も氏と同じである。aspxの編集は、原則テキストエディタで行っている。私たちのASP.NETの生産性をより高めるためには、Visual Studio開発チームによるデザイナの改善が必須だろう。

リファクタリングをaspxに反映できない

氏の意見に賛成だ。私が開発に使っているVisual Studio 2005にもリファクタリング機能があるが、ASP.NET開発では使えるとは言い難い機能だ*4リファクタリングの対象からaspxが外れているのだ。たしかに、aspxをリファクタリングの対象にしようとすると、リファクタリングの過程でページの実行をエミュレートしなければならなさそうなので、難しいのはわかる*5。しかし、そのせいでASP.NET開発者はリファクタリング機能の恩恵を受けることができておらず、ソースコード全文検索による旧時代的なリファクタリングを行っている*6。(しくこくなってきたが)Visual Studio開発チームには、この点の改善も希望する。

LINQ to Entitiesが利口でない

この点については、私は未だLINQを使ったことがない時代遅れプログラマなので、何とも言えない。
LINQと直接は関係ないのだが、データセットデザイナの完成度も褒められたものではない。詳細は以前のエントリでも書いたが、設計上の最大の問題点はジェネリックを使用しないコードを自動生成する点だろう。Oracle上でNULL許可なNUMBER型の列があれば、Nullable<Decimal>*7マッピングしてくれればそれで良いのだ。Visual Studio 2008なら改善されているのだろうか。

SqlDataSourceの設計がおかしい

(1) Parameter.DefaultValueプロパティがString型
氏の意見は、Object型にすれば良いということだろうか。たしかにそう思える。
ただし、現時点のASP.NET*8の実装では、String型しかあり得ないことになる。理由は以下のとおりだ。

  1. プロパティをaspxで設定可能である
  2. aspxで設定したプロパティは、ASP.NETランタイムによっていったんStringオブジェクトとして読み取られる
  3. Stringオブジェクトとして読み取られた値は、ASP.NETランタイムによってプロパティの実際の型のオブジェクトに変換される*9
  4. 実際の型は、Parameter.Typeプロパティで指定されたTypeオブジェクト*10が表す型である
  5. 任意のオブジェクトからTypeオブジェクトが表す型のオブジェクトへの型変換を行うことはできない

以上より、aspxから読み取られたStringオブジェクトを、Parameter.DefaultValueプロパティに設定したい型(Parameter.Typeプロパティで指定されている)のオブジェクトに変換する術がないために、Parameter.DefaultValueプロパティがString型なのだと思う。
このような事情があるにしろ、氏が言うように単純に違和感を感じる設計である。「任意のオブジェクトからのTypeオブジェクトが表す型のオブジェクトへの変換」さえできれば解決するのだ。また、それさえできれば.NETでのプログラミングの可能性が飛躍的に高まるのだが、なぜできないのだろうか。いつか考察したい内容である。
(2) SqlDataSource.Selectメソッドの引数指定が必須
氏の意見に賛成だ。

*1:これは私が悪いが

*2:Visual Studio 2008でどうなっているかは試していないが

*3:正確にはascxやmasterを含む、いわゆる「マークアップ

*4:ないよりは良いというレベル

*5:正確に言うと、技術的にはできるがパフォーマンスを出すのが難しいのだろう

*6:はずである

*7:リンク先はNullable<T>構造体

*8:私が知っているのは2.0だが

*9:この辺りの仕様は複雑なので、またいつか個人的な備忘のために記述しておきたい

*10:ちなみにこのTypeオブジェクトについても、(値をaspxで指定したのであれば)Stringオブジェクトからの変換が行われた結果である