読者です 読者をやめる 読者になる 読者になる

きよくらの備忘録

「三日坊主と呼ばせない!日記」改め。主にソフトウェア開発関連の話題。

ORMとかdapper dot netについてお話させていただきました

10/13に開催されたイベント、『ヒーロー島 秋の収穫祭』に参加してきました。


[追記:デモで利用したサンプルコードを公開しました]

当日の様子

当日はヒーロー島の上本さんや松浦さんの他、この10月にMicrosoft MVPを受賞された西村さん、さらに北陸からこられたスーパー主婦でMVPのさくしまさん、日本マイクロソフトからは長坂さんと、豪華なメンバーでのセッションが行われました。

さくしまさんと西村さんの当日についてのエントリはこちら。


大変楽しいイベントでした。来年の収穫祭も楽しみです*1

私も.NETのDBアクセステクノロジーについてお話させていただきました

そのような講師陣に僭越ならが私も混ぜさせていただき、「ADO.NETとORMとMicro-ORM −dapper dot netを使ってみた」というタイトルでお話させていただきました。当日の資料やサンプルコードは下記の通りです


...実は前の週に同じく広島で開催された第二回 中国地方DB勉強会にて同じくdapperとMicro-ORMについお話させていただき、今回はそのマイナーアップデートのつもり…だったのですが、参加してくださる方のバックグラウンド等々を考えた結果、資料からして8割くらい新規作成となって全然違うものになってしまいました(ちなみにその時の資料はこちら*3

フォローアップめいたお話

少しだけ、フォローアップめいたお話。

当日の話の流れとしてはこんな感じでした。
  • ADO.NETのおさらいを兼ね、「生ADO.NETでやるとこんな感じに手順が多いよ、ちょっと面倒だよね」というのをデモで感じていただく
  • ORMのざっくりしたお話と、ASP.NET MVCとEntity Frameworkだとこんな感じですっごい簡単にできます、というデモ
  • ORMで全て解決できるわけじゃないし向き不向きはある、という話
  • それを受けて、ORMと生ADO.NET以外の選択肢としてdapper dot netはどうでしょう、というご紹介
ORMは決して銀の弾丸じゃない

資料で書いていることと重複しますが、ORMが便利で有効に働くかどうかは、設計に大きく依存します。
もちろんORMを基準に設計すればそこはクリアできると思います*4。しかし全てのケースでそれが『そのシステムにとっての正しい設計』につながるかというと…私は『No』なんじゃないか、と思うわけです*5

幸いにも.NET Framework(やその上で動くMVC等のフレームワーク)では「データアクセスにはこのORMを絶対使わないとダメ!」という縛りがあるケースは少ないようです。例えばASP.NET MVCでも、デモでもお見せしたようにEFを使うとスキャフォールディングで色々作ってくれる機能を持っていますが、モデル部分に採用するテクノロジに縛りはありませんので何でやっても問題ないです。


ということで、ORMを使っていて「ORM使うために構造が無駄にややこしくなる」「パフォーマンスが出ない」なんてことになって、「なんか逆にしんどい」と思ったら、ORMを使わない選択肢も考えてみると良いと思います。


そしてもしそうなった場合は、dapperはちょうどいい選択肢になりえるじゃないかな、と思います。

念のため

と、最後に念のために書いておくと、私はORM否定論者ではありません。ORMを使って楽が出来る、問題ないときはどんどん有効活用すべきだと思います*6

P.S.

あと、今回、DataSet(とDataTable)はまったくといっていいほど触れませんでした(型付データセットも)。正直なところ、DataSetはそろそろ、よほどの理由がなければ使わないほうが良い…というのが現在(というかずいぶん前から)の私の考えだったりします。

*1:[http://sakematsuri.com/:title=翌日の祭り]も楽しかったですが、それはまた別のお話:p

*2:MVC+EFのデモは同梱のsdfを使ってEDM→スキャフォールディングしただけのデモの為、サンプルコードは割愛しています

*3:資料作りで楽するつもりだった目論見がすべて外れたという(^^;

*4:多分:p

*5: もちろん、それで設計として問題ないケースもあると思います。

*6:実際、私も普通に使う時は使ってます。それが一番楽だ、と思ったときは。