λ [.NET] なま暖かくて柔らかい、ちょっと触るとプルプル動く

ITemplate の日本語の記事は mumurik さんの以外何かないかなーと思って探したら当たった。 俺も常々「何でいちいちEvalなんつー遅いもの使うねん」と思っていたところなので参考になった。 ASP.NET で何らかの「部品化」を狙っているならとてもいい入り口だ。

DataBinder.Eval が登場した理由は、VisualStudio的にはWizard操作している時点で本物のデータを持って来てコードを生成できるんだけど、 「コンパイルの時点ではそんなものは忘れているので致し方なく」 VisualStudioをポチポチ触って生成されるコードは DataBinder.Eval になるんだと思われる。

しかし SqlDataSource よりは ObjectDataSource のがましよのう、と思った矢先に、「自分で DataSourceControl を派生しよう」という話に当たるとちとへこむ。

…ソースコードを読んでいると、クラス名がわかりずらい。HogeItemViewがプレゼンテーション用で、HogeViewがデータ用ってどうよ。

• HogeListView がやっていることはほぼ Repeater なので「俺Repeater」だと思う
• HogeItemView がやっていることは Repeater が中で持っているプレゼンテーション用の各要素。なのだが、aspx内のテンプレート上で Container 変数に割り当てられるので、プログラミング上ではContainer変数が使いたいプロパティまたはメソッドを定義する。DataBinder.Eval の流れでItemプロパティとして定義されることが多いような印象があるが、むしろ GetHoge() みたいなメソッドとして定義する方が見た目分かりやすいのではないか?Itemと書いてあると、ぱっと見なんだかさっぱり分からない。日本語メソッド勝負だったら、「データ取得()」かなあ…

λ [.NET] VS2005周辺の開発環境(TeamSystem以外)

うまいこと安価で入手できたからTeamSuite持ってるけど、社員全員にTeamSystem配るのはどう考えても高すぎだもんなあ… しかもTeamFoundationServerの構築は一筋縄ではないときている。

しかもSubversion+Tracでソース管理とタスク管理はまあまあ回っている。

OnTime 2006 のWorkflowは完璧自分とこと一緒。Tracの状態遷移はバグトラッキングとしてもいまいちだったので、魅力的だ。 しかもこのWorkflow、担当するべきRoleが明記されているのが素晴らしい。それでも今Tracを離れるのは厳しいなあ。

ReSharpar+NUnit への移行は現在検討中。単体テストは無駄に TeamSystem に依存した生活をしている。

λ [.NET] Using CruiseControl.NET with MSBuild

ビルドに関しては MSBuild は悪くないと思ってるので、ちと調査

λ 1クラス1ファイルの原則

原則は原則として、DataSourceControl+DataSourceView とか、ITemplateでInstantiateInする側とされる側とか、 実装が一心同体な感じな奴は2クラス1ファイルでもいいと思う。