NHibernate
今仕事では.NET/C#で開発してるんですが、
DBアクセスにはNHibernateを使っています。
NHibernateはJavaのHibernateを.NETに移植したものです。
ちなみにHibernateはハイバーネイトと読みます。
最近までヒルベルトだと思ってた･･･
HibernateはO/Rマッピングフレームワークです。
O/Rマッピングフレームワーク(O/Rマッパー)とは、
OOPLのオブジェクトとDBのレコードを対応付けることによって
DB入出力+変換という作業を自動化するものです。
Hibernateでは対応付けをXMLによって記述します。
RoRとかだと名前見て自動でマッピングしてくれるんですよね。
O/Rマッパーを使うとSQLを書かないで済むのがいいですね。
プログラム(OOPL)の中にプログラム(SQL)を文字列として
記述するのってどうも気持ち悪いんです。
CGIなんかもそうですけどね。
Lisp以外のevalは使いたくないということです。
Lisp/evalの引数は文字列じゃなくて普通のS式だから許せるのです。
だからC#3.0のLINQは僕は歓迎です。
LINQによってSQLを文字列として記述する必要がなくなります。
HibernateはDBにアクセスする手段として以下の4つの方法を提供します。
・O/Rマッピング
・Criteria
・HQL
・SQL
SQLはまぁ一応使えるけどHibernate経由にする意味はほとんどないと思います。
単純なO/Rマッピング機構だけで事足りることはあまりないので、
柔軟なデータアクセスが必要であればHQLかCriteriaを使うことになります。
HQLはSQLに良く似た言語だけど、テーブル/カラムの代わりに
クラス/プロパティを使ってデータを指定します。
session.CreateQuery("from Person as person where person.Age = 13");
HQLはSQL同様に文字列なので、
条件指定などを動的に行う場合には文字列の連結で表現することになるのが嫌ですね。
そういう人のためにCriteriaというものが用意されています。
session.CreateCriteria(typeof(Person))
.Add(Expression.Eq("Age", 13));
Criteriaの方がやや冗長度は高くなり、
おそらくパフォーマンスは悪くなると思います。
ひとつ条件加えるたびにオブジェクトが生成されるんで。
NHibernateのおかげでデータベース周りは大分すっきりして良いんですが、
まだ.NET2.0に対応していないのがちょっと痛いです。
特にSELECTで取ってきたオブジェクト群が
Generic Collectionになってくれないところと、
Nullableに対応していないおかげで、
構造体のNULL書き込みができないところが痛い。
半分使えて半分使えない環境で開発してると、
Genericsが如何にありがたい存在かを実感させられます。
IListって.NET1版と.NET2のGenerics版の2つが
名前空間分けて共存してるんですね。
でデフォルトはGenerics版が参照されるようになっててはまりました。
# using System.Collections.Genericしてないのに何故か参照できる？
旧Listを新Listに代入するとnullになっちゃう？なんでーと悩んでいたんだが、
今気づいた、as演算子使ってるからか･･･
キャストしていれば例外が飛んでもっと早くに気づいたかもしれない。
見た目重視でついついasを使ってしまうのでした。
ハイバーネイト読みにくいよね…
読み方知ってるんだけども、
俺はヒブルネイトって読んじゃうw
仕事で使った感想はXMLめんどくさの一言w
ソースはきれいになってよい感じでしたが。
O/Rマッパー便利だよね。
前からソースコード内にSQLが入るのは違和感があったんだよ。
今研究でPerl使っているけどPerlで使われているO/RマッパーはClass::DBIかな。Class::DBI単体だけだとプログラム中に設定項目を書かないといけないけど、Class::DBI::Autoloderを使うと書かなくていい。
んで、両方ともやったことあるんだけど、設定項目は書かないほうがいいな。
俺もヒルベルトと呼んでたよｗ
ハイバーネイトとって発音しにくいなぁ。
ヒルベルトでいいよ！＾＾
やれやれ、休止状態世代共ﾒｶﾞ('A`)
昔は、suspend -> hibernate、だったものを。
今では、サスペンド -> 休止状態、か。
いやまて、待機状態 -> 休止状態、みたいな表現を見た希ガス。
中華、O/R mapって、言語ごとに予約語とかが使えなかったりするんで、
直接フィールドにするってのはイマイチだ。
あと、自動でテーブルの情報を取ってこないようじゃ役に立たんな('A`)
ま、何はともあれ、テーブルの定義を共通化するのと、テーブルへのアクセスを共通化する、てのは、
そのうちやらないといかん話だな。
ま、便利さと効率は両立しないんで、その辺り段階化できるようにしないといかんな。
>>acht
>仕事で使った感想はXMLめんどくさの一言w
一回サクッと対応付け書いて終わりではないのかな。
僕の場合、テーブル構造はかなりシンプルなのでそんなめんどくなかったです。
>>よこち
>書かないといけないけど、Class::DBI::Autoloderを使うと書かなくていい。
なるほど。
デフォルトでは明示マッピングが必要だけど、
オプション使うと自動マッピングもできる、てのは個人的には好みだな。
>>ヒルちゃん
>ヒルベルトでいいよ！＾＾
脳内ではいいけど、
人と話すとき間違ってると恥ずかしいですｗ
>>wiz
>いやまて、待機状態 -> 休止状態、みたいな表現を見た希ガス。
ほぉ。
永続化のことを指してるのだろうか。
>中華、O/R mapって、言語ごとに予約語とかが使えなかったりするんで、
ごめん意味わからん。どゆこと？
>あと、自動でテーブルの情報を取ってこないようじゃ役に立たんな('A`)
自動マッピングのこと？
命名規則を考慮しないといけないのも微妙だけどな。
>永続化のことを指してるのだろうか。
Windowsのことよ。電源管理のところで、hibernateが出てくるという話。
classつーカラム（列）があると、rubyでobj.classと重なってｱﾎﾞﾝﾇ（´Д｀）
>命名規則を考慮しないといけないのも微妙だけどな。
railsはテーブル名は複数形になってるけど、普通に命名規則無しで良いかと。
userという名前のテーブルはuserというクラスでモデルに、nameというカラムはnameというフィールドに、つー感じで。
直接フィールドにするとアレなこともあるので、db_が頭につくと良い感じか。
リレーションは自分で書くので問題なし。ただし、簡単に記述できなきゃね。
> eclipse
書いてしまえば楽なんだけど、Railsが楽なもんでw
制約はされてるけど。
ちなみにhibernateってアソシエイション関係まだ不完全じゃなかった？
> wiz
hibernate普通にlinux終了するときに出てくる。
ま、正常に終了しないんで意味ないけどねw
>>wiz
>classつーカラム（列）があると、rubyでobj.classと重なってｱﾎﾞﾝﾇ（´Д｀）
うん。それは自動マッピングの欠点だよね。
>userという名前のテーブルはuserというクラスでモデルに、nameというカラムはnameというフィールドに、つー感じで。
小文字でクラス名ってできないよね。
テーブルの方を合わせるのかな？
>>acht
>アソシエイション関係
ごめん用語わからん。
>テーブルの方を合わせるのかな？
データベースの列名やテーブル名は普通大文字小文字を区別しないので、
大文字に変換しちゃっておｋ（ﾟ∀ﾟ）
>ごめん用語わからん。
リレーションシップ、と読み替えてやってくだせぇ('A`)
ちなみに、railsではhas_manyとかで、リレーションを結べるんだけど、
効率的な部分で微妙な感じね。
has_many :members
とかで、そのモデルの持つmember_id列が、membersテーブルの主キーに結びつく。
でも、リレーション張りまくるとバグるんだよね、これが。
あーそういうのならHibernateにももちろんありますよ。
あんまり使い込んでないので、
どういうところが足りないのかはまだわかりませんが。