■

■LINQ to SQL雑感
常駐先の現場で、余剰になったマシンを半ば強制的に奪取し、VS2008の実験環境とする事ができたので、以前から気になっていたLINQにおけるDBアクセスを、実験モジュール（WindowsForm）にて、実現させてみた。
まずは、『ボタン押下→LINQによるDBアクセス→結果をGridViewに出力』という、オーソドックスなサンプルを作成した。使用の第一印象としては、慣れの問題もあってか、正直微妙と言ったところ。結果が画面表示された時こそ、感動を覚えたものだが、従来の『ADO.NET＋SQLを組む』の方が、脳内でスムーズに組めてしまう始末。要塞SQLを相手にし過ぎた代償であろうか。

LINQを書くに当たり、つまづいた点が、1つ。
参考にしたサンプルガイドでは、Contextクラスのインスタンスを生成する際、usingで明確にスコープを切っており、その中でGridバインドを行っていた。つまり、『LINQアクセス→結果をセット』まで、同一クラス内（この場合、Formクラス）で実施している事になっている。これだと、論理ティアごとに、プロジェクトが異なる場合、ガイド通りには実現できない事になるわけで…。usingの明示的なスコープ切りを止め、Entity階層から、LINQで使用するIOrderedQueryableを返却する（Formで返却値IOrderedQueryableを受け取る）とか、乱暴な事して良いのだろうか（これでできてしまった）。
DataTableに詰め直したりする必要性が出てきた場合にも、スマートにいかず、難儀しそうな予感が…。そんな"場合"が発生しない代物なのであろうか？
…そもそもの捉え方が違うのかもしれない。LINQを使用するに当たり、何か独特な『LINQアタマ』が必要だったりするのか？

ひとまず、もっと勉強して、旨みを理解できるまで、実験する必要があると感じた。

■

■ASP.NET MVC Framework の存在
名称を聞いただけで、javaっぽいと直感したASP.NET MVCは、従来のASP.NETの問題点を解決するために生まれたようだ。
毎度悩まされるWebFormのテストや、非ASP.NETな方々に優しくない、独特なPostBack、ViewStateの利用を解消するメリットは有りそうだ。
ただ、サーバーコントロールを廃止し、埋め込みブロックによるコード記述を行う（コードビハインドの価値が…）といった方式は、従来型FWで開発を行ってきた小生には、先祖返り感さえあるのは否めない。

サーバーコントロールの恩恵を享受できないのは痛手だが、非ASP.NETなWeb開発者からすれば、きっと取っ付き易いFWであろう。

安堵したのは、MVCが従来型に取って代わる存在ではなく、共存的立場にある事。双方、開発において一長一短があり、開発陣営の状況に依るところとなる。
やはり、javaな人⇒MVC、WindowsFormな人⇒従来型といった感じだろうか？

常駐先のプロジェクトで、WindowsFormとWebの区別が付いていない上層や開発者がいる中で、Web開発を推進していたという楽しい状況下では、従来型ですら、持ち腐れになってしまうわけだが。
C#、C#と連呼したところで、「C# = WindowsForm開発」でもなく「C# = Web開発」でもござらぬ。言語ですから。これでは、MVCやら従来型のへったくれもない。

終いには「お前は、出来る面子の中じゃないと、仕事が出来ないのか？」と自社の上司に叱られ、つくづく、プロジェクトとは「人」なのだ、と実感した次第。今後、どんなFWが出て来ようと、それを扱う面子が勉強する姿勢のない連中では、苦戦を強いられる。そうした状況下で、いかにスキルと開発効率を上げるために振舞えるか…次回、このような状況に直面したら、先輩が他プロジェクトで実践していた方法を試してみようと思う。

自身の勉強不足は棚に上げて、プロジェクトについてあれこれ思慮させられた、ASP.NET MVCの、存在。

SQLServer環境下でのクエリの高速化

SQLとは長い付き合いで、他のメンバーが言うほど組む事は嫌いではないのだが、いまいちチューニングに関しては頓着してこなかった。

チューニング素人が今回学んだのは、FORCEPLANなる句。
汚いDB下で要塞のようなSQLを組んだのだが、DBの件数が増加すると、著しくパフォーマンスが落ちた。
多数のJOINと副問い合わせが原因なのだが、結合の順序に気を遣っても、性能改善はされなかった。これは、SQLServerが実行時に最適な結合を模索するためだが、こちらの思惑通りの結合順序で処理してくれるとは限らない。そこを強制的に"書いてある通り順番に"処理を行わせるのが上記の宣言。

SET FORCEPLAN ON

SELECT …

と続ければ、OK。
宣言で"OFF"にすると、SQLServerにお任せとなる。チューニングについて、色々習得すれば、もっとSQLが楽しくなるかもしれない。

ASP.NET2.0におけるスクロールバーの選択位置保持について

ASP.NET2.0で、ブラウザのスクロールバー選択位置保持を行う場合、「MaintainScrollPositionOnPostback」を使う。
大仰なプロパティ名だが、私の知っている「SmartNavigation」は使用中止命令が出たらしい。MSDNにも、互換性のため仕方なく残しておく旨が綴られている。
2.0β版の時は「SmartNavigation」だった気もするが、気のせいか。いずれにせよ、代替として大仰な方を使う事になったようだ。
http://msdn.microsoft.com/ja-jp/library/system.web.ui.page.maintainscrollpositiononpostback(VS.80).aspx

CSSの優先順ポイントについて

Web開発を行って来ていながら、これまで優秀なデザイナに恵まれ、自分でstyleを意識することも無かったのだが、最近、そうも行かない。
否応なしに、対応を迫られているので、今更ながら、少し勉強した。

CSSの効力には優先順があり、定義の仕方次第で、かなり自由度高く思い通りのstyleを設定できることが判明。

中でも無知な自分にとって、「ポイントルール」は驚愕だった。

*（全称セレクタ）⇒0ポイント
p,h1等のタグ⇒1ポイント
.aaa（classの場合）⇒10ポイント
#aaa（idの場合）⇒100ポイント

といった具合で、ポインタは複数並べることで加算されていく。

p.aaa＝1＋10＝11ポイント
.aaa p＝10＋1＝11ポイント
#aaa .sample＝100＋10＝110ポイント
#aaa .sample p＝100＋10＋1＝111ポイント

ポイントが同じであれば、後に記述した方が優先となる。
また、範囲を限定して使用したい場合は、使用範囲をdivタグで囲い、class or idを設定して、styleを適用する。

ASP.NET2.0にてjavascriptによる連携DropDownList

PostBackなしに、2つのDropDownListを連携させる（ddl1の選択値によりddl2の内容を動的に構築する）際の、備忘録をば。
以下はjavascriptのサンプル。

var list = new Array("0", "0,1,2", "0,1");
function SetDdl2Items(){
var se11 = document.getElementById("ddl1");
var sel2 = document.getElementById("ddl2");
var ops = new Array(
new Option("値1","1"),
new Option("値2","2"),
new Option("値3","3"));
var indexes = list[sel1.selectedIndex].split(",");
while(sel2.options.length > 0){
sel2.options.remove(0);
}
for(var i=0; i

Arrayを組み立てる辺りと、listを組み立てる辺りをサーバーサイドで作り、ClientScript登録する。初期表示にも対応するが、javascriptで内容を構成したddl2は、サーバーコントロールを使っていてもchange系イベントを捕捉することや、selectedValue、selectedIndexを取得することは適わないようだ（暫定回避策は後述）。
加えて、ViewState解釈のセキュリティチェックの兼ね合いか、submit等によるPostBackが発生した際、内容再構成ができずに、「無効なポストバックまたはコールバック引数です。」のようなエラーとなる。これについては、Renderをoverrideし、ClientScript.RegisterForEventValidationで回避可能。
（<%@ Page EnableEventValidation="false" %> を記述する手もあるが、どうみてもこれは実践ではやりたくない。http://msdn.microsoft.com/ja-jp/library/system.web.ui.page.enableeventvalidation.aspx）

PageのRenderイベントハンドラにて
ClientScript.RegisterForEventValidation(ddl1.UniqueID, "値1");
ClientScript.RegisterForEventValidation(ddl1.UniqueID, "値2");
...
(↑実際は当然、ループで)

また、これ以外にも、DDLカスタムコントロールを作成し、以下の処理を加えることで回避可能。

protected override bool LoadPostData(string postDataKey, System.Collections.Specialized.NameValueCollection postCollection)
{
string value = postCollection.GetValues(postDataKey)[0];

if (value == null && this.Items.FindByValue(value) == null)
{
this.Items.Add(value);
}
return base.LoadPostData(postDataKey, postCollection);
}

更に、submit時にselectedValue等を取りたい場合（検索条件として使う場合とか）、少々強引ではあるが、あらかじめ、通常のサーバーコントロールDDLを使うが如く、初回にItemをBindしておけば、サーバーコントロールとしての面目も保たれるようで、javascriptによる動的内容構成を行っても、selectedValueが利くようになる。これについては、もっと正しいやり方があろう。
ひとまず、これにて。

.NETFramework4.0の概要が発表された

3.*も触れていないのに、4.0の概要が9月29日にMSから発表されたとのこと。次期IDEはVS2010となる模様。

  • 主眼
    • アプリケーションライフサイクル管理（ALM）の役割均等化
    • クラウドコンピューティングのような最新技術傾向への対応
    • 開発者の開発意欲を刺激
    • 次世代プラットフォームの波に乗る
    • 部門から企業全体へというアプリケーション開発の流れをサポート

とある。TFSとの連携強化等も盛り込まれているが、"4.0"の呼称にいまいちピンと来ない…。まだ、公表された内容が抽象的な気がしていて、3.5のマイナーチェンジくらいに留まっているのでは？と思ってしまう。
今後の情報に留意する方向で。

それにしても、『開発者の開発意欲を刺激』とは、一体…。
VS2010、4.0の発表により、既に、ついて行けない…と開発意欲を削がれている私の上長もいるわけだが。