自分が読みたいのはInside Expressionsであり、How to Implement custom LINQ providerな内容(`・ω・´)

っということで、お目当ては11章と12章でした(・∀・)

プログラミング MICROSOFT LINQ (マイクロソフト公式解説書 Microsoft Visual Studi)

プログラミング MICROSOFT LINQ (マイクロソフト公式解説書 Microsoft Visual Studi)

我々Providerを実装するかどうかはおいといて、この辺の知識は我々フレームワークを作る上での参考にもなるしね(・ω・)
まあ、参考という意味では実装のサンプルを見た方が早かったりもするので、CodePlexにあるLINQ実装の例を落としてきてソースを読むのも良いかもだけど。*1


あと、LINQ実装以外でチェックすべきところとしては、次のあたりかな(・∀・)


LINQ IQueryable Toolkit
http://www.codeplex.com/IQToolkit

LINQ Extender
http://www.codeplex.com/LinqExtender

MetaLinq
http://www.codeplex.com/metalinq


どれも我々Provider作成の為には便利なものですが、例えばIQToolkit.Data.DbQueryProviderなんてものがあったりして素敵すぐるヽ(゚∀゚)ノ
内容については、この辺を参考にするとして。
http://blogs.msdn.com/mattwar/pages/linq-links.aspx


っで、データベースアクセスに関して言えば、LINQ to Entitiesみたいな方向だけが望まれているものではないと思うわけですが(・ω・)
LINQ to SQLですら余計な部分があって、SQL文字列を生成することと、DTOに結果をマッピングすることにのみ注力したProviderとかあっても良いと思うんですよ。
オブジェクトのトラッキングとかはいらなくて、その代わりUPDATEやDELETEは柔軟にやりたいんですよと言うか。
要は、O/R MapperではなくR/O Mapperが欲しいというか、HibernateではなくiBatisを使いたいというか、そんなカンジ(・ω・)


前にASP.NET MVCで行くときの、モデル層の設計方針で悩んでいたのもこのあたりで(´д`)*2
普通に考えると、LINQ to SQLを使って、Repositoryを作って、っという風になりそうですが、はたしてそれがベストかなぁと。
OOっぽく、格好良くやるだけが選択肢じゃなくても良いよね〜、っと思った次第(・ω・)


その他、この本を読んでて思ったこととしては、.NETの話ではなくてJavaの話になるんだけど、Javaにもやっぱりクロージャとプロパティは欲しいよね〜、とか(・∀・)
なぜかと言うと、Javaでもfluent interfaceを使ってSQLを構築するタイプのデータアクセスライブラリがありますが。
でも、メタ情報の表現とかが微妙だな〜、と思うものもあったりして(・ω・)
条件の指定も、クロージャで指定して、Language IntegratedなExpressionで実装した方がやっぱりスマートだよなぁと。
そもそも、Expressionを構築していってそこからQueryを作るのと、Queryをfluentに構築していくというのでは、本質的に違うものだしね。*3


…なんて所がLINQ本を読んでの感想です(・∀・)
っで、今月はLINQ本の他にASP.NET MVC本とかを読んでいたわけですが、そういえば書いてなかったので、ついでにその他の読んだ本の感想も書いておきます。


C# .NETアプリケーション開発 徹底攻略 C# 3.0/.NET Framework 3.5対応

C# .NETアプリケーション開発 徹底攻略 C# 3.0/.NET Framework 3.5対応

思ったよりも面白そうだったので買ってみました。
こういう、実際の開発者視点からの考えの本ってのも珍しいよね〜(・ω・)
とりあえず、IBM Rational PurifyPlus(・∀・)


リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

一番気になったのは、やはりドレイファスモデルの話かな。
看護師の話は実に興味深い。
日本的に言えば、SE=医師、PG=看護師みたいな話ですかね(´Д`;)?


世間一般で言うSE/PGっていう区分けも、実に馬鹿馬鹿しいと思うわけですが( ゚д゚)
自分がSE/PG的な区分けを認識したのって、実は働き始めてからけっこうたってからの話だったりして(´Д`;)
はじめはその意味が分からなかったっというか、その区分けって、単に外見せの単金テーブルの違いじゃね?、くらいにしか認識していなかったし。


世間一般での使い分けを知ったときには、(゚Д゚)ハァ?、意味わかんねっと思ったというか。
実装を知らずにBDUFとか、単なるコーダだとか、オマエラ真面目に(効率的に、利益を上げて)仕事をやるきあるのかよ(#゚Д゚)、っと思ったものですよ。
まあ、SE/PG的な区分けをあたりまえに使っているところでは、きっと楽しく働けないと思うのデス(´・ω・`)


あと、本の話に戻ってですが、脳の構造の話でDSPのたとえは言い得て妙だと思ったりしてネ(・∀・)


プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

これは、個人的にはちょっと、ふ〜ん感があったかも。
Macあまり使っていない…(´・ω・`)

*1:CodePlex上だとSimpleDB、ExcelLuceneとかがあるし。

*2:あと、PI(Persistence Ignorance)とIPOCO(Interface + Plan Old CLR Object)のあたりの話も。

*3:Queryの再利用とかさ、そこは割り切るというのでも良いんだけど(´д`)