【.NET】ADO.NET再入門

ここのところDBを使わない小さなアプリの開発や共通チームから提供されたDA層の訳わからんAPIを文句を言いながら使うというようなお仕事だったのですが、担当プロジェクトが停滞し空き時間が出来た事もあり、久々にADO.NETを弄ってみました。

気が付いたら僕がよく使っていたDataSetは過去のものとなり、LinqToSQL⇒EntityFrameWorkと進化していました。
いつの技術使ってんだよ?って?
本当に不勉強でお恥ずかしい限りです・・・。
なにせせっかく高いお金払ってせっかく.NET採用しているのに、いまだに生SQLで全て記述するような底辺スキルのお仕事ばかりなもので。。

ADO.NET、いろいろ課題はありますが、確実に進化しているように感じました。
各々を少し触ってみた感触を軽くまとめてみたいと思います。
概要レベルや論理レベルでのプログラミングの実現とか僕の世界とは無縁の高尚なお話もあるようですが、あくまで現場レベルの使い勝手について。。

【DataSet】
SQL上等でプログラムしていた当時、担当システムの基盤部分を一任された事により独断で導入してみました。
僕が担当でなければ相変わらず生SQLをチマチマ書く生産性とは無縁の世界となっていたでしょう。そんな底辺世界でがんばって生きています。。
SQLやコードを書かずにACCESSチックなUI操作だけでDA層が実装できてしまう手軽さにさすが高いだけあるわ・・・と当時はちょっと感動しました。
ただお馴染みレイアウトが固まらないテーブルの餌食となったり(ここが後続の技術に対しての明確な欠点?)、メンバー複雑怪奇超巨大クエリを作成(今なら瞬殺でストアドにせいやと言える。。)して泣き入ったりと誰もが通るであろう痛い目もみました。。
せっかくの型付DataSetがテーブル結合には対応できないのも残念と言えば残念。
あとIsなんちゃらNullもアカン感じ。。

【LinqToSQL】
クエリの類がエンティティから切り離されており、DataSetの欠点であるDB変更に弱い点がある程度解消されたんでしょうか。
データ取得はLinq&ラムダなC#ユーザー大喜び。
プログラミング上の使い勝手としてはEntityFrameWorkとそんなに変わらないように思えるので、現時点でも現役で使えるかな?
逆に我が底辺環境で導入するにはLinqが高いハードルになりそう。
底辺エンジニアは新しい技術なんて勉強する気なんてないですから。。
Linqとかラムダとか使うと可読性が落ちるとかお叱りを受けかねないし。
(もうVB6でいいんじゃね?)

【EntityFrameWork】
なんだか小難しいお題目を掲げていたので身構えましたが、要するにLinqToSQLの進化版なのかな。
データアクセス方法もほとんど同じだし。
以前のテーブルからエンティティ作成だけでなく、エンティティからテーブル作成が出来るようになってる。
まあ現実的にはそこそこの規模のシステムはテーブル設計ありきになってしまうので、細いアプリをサクっと作って試したい時に活きるくらいかな?
自動生成がうまくいかなかった時にDataSet、LinqToSQLよりもガッツリドップリとハマりそうな予感。。

【まとまっていないまとめのまとめ】
現時点ではやはり最新(というほども新しくない)のEntityFrameWorkを使った方が良さそうですかね。
ただ底辺環境では高い生産性よりも低スキル派遣エンジニアが新たに学習しなくてもなんとか形に出来て、技術に疎いプロパーSEがどうにか理解できる開発環境が求められているので、有効利用は難しいだろうなあ・・・。

もうなんか高いお金払って拳銃買ってきたのに、中の弾丸取り出して敵に投げつけるような使い方しかできないのはどうなのよ。。。