SQL文だけ書けば自動化してくれる、ということ以上に
という一連のシチュエーションで、SQL文の変更を忘れにくいというのがメリットなんだなと思った。
データセットにFillする時のSQL文のみならず、スカラー値を返すクエリも書ける。 要するにデータアクセス層はここで完結させるべきで、partial class のパワーもあって C#コードを追加することも可能。
要はデータアクセス層なのではあるが、図がほぼ自動的にメンテナンスされるありがたさ。
impersonate (偽装) により実行アカウントを変更した場合に、dotTrace 側が例外を起こしてプロファイルが取れないことがあった。 dotTraceの中なので詳細は分からないが、CryptographicException だったんでその辺は外部からちょっかい出せなくてもしょうがないかも。
プロファイリング取った結果は、DataSet+XmlSerialiver のあたりで上位7位。 自分で書いた部分のホットスポットは8位でやっと登場して 2.24%。 この部分も予想通りのループにあったし、さすがにバックエンドロジックを一人で書いただけあってほぼ想定内だ。
Reporting Services の中は VB しか使えなさそうなのだが、VBの流儀で書きたくない俺。
かといって、別プロジェクトで C# のカスタムアセンブリを作る のも面倒だと思っていたが、カスタムアセンブリの参照が出来るんなら System 名前空間は当然使えるよな。
郵便番号の3文字目の後ろにハイフンを入れる、textbox への Value の指定:
=System.Convert.ToString(Fields!郵便番号.Value).Insert(3, "-")
これならC#でaspx書いてるのと全然変わらないぞ! しかも式ビルダの中ではちゃんとIntelliSenseが効く。
ちなみにこうなる直前は
=CStr(Fields!郵便番号.Value).Insert(3, "-")
と書いていた。VB.NET って奴はなかなかのヘテロ環境である。