Hibernateの.NET版であるNHibernateというものがあります。
http://wiki.nhibernate.org/display/NH/Home
.NETでO/Rマッピングを実現する手段は他にもありますが、
見たところではNHibernateが最もポピュラーなようです。
.NETの場合にはADO.NETがありますし、VS.NETを使えば
とても簡単にデータソース設定ができます。Hibernate
の場合には面倒なxml設定(***.hbm.xml)がありますが
それがないのはとても楽ですね。
そういうメリットがあるにも関わらず、NHibernateに
注目が集まる背景にはやはりアーキテクチャ的な視点が
あるように思われます。
Martin Fowler氏のPoEAAに当てはめれば、ADO.NETは
ドメイン層には「Service Layer」+「Table Module」
ドメインソース層には「Table Data Gateway」という
ことになります。DataSetがTable Data Gatewayに
相当するという捉え方です。
この場合、Table Moduleは通常一つのテーブルに対応
することになります。単一のテーブルへのアクセスを
考える上ではとてもすっきりした構成なのですが、
複数テーブルから一つのドメインモデル上のデータを
生成したいといったようなケースがあると、それらの
データ結合処理をService Layerに持ち込んでしまう
ということがありえます。そうすると、Fowler氏が
言うところの「ドメインモデル貧血症」を引き起こす
恐れが出てきてしまいます。
こうしたことを踏まえて、.NETの世界においてもO/R
マッピングのパターン、つまりは
ドメイン層には「Service Layer」+「Domain Model」
データソース層には「Data Mapper」
という構成を実現する手段が望まれたのではないか
と思います。実は本家のMicrosoftからそうした解は
既に提示されてはいます。「Object Spaces」という
もので、まさに.NET版のO/Rマッパーそのものです。
当初はVS.NET2005(Whidbey)と同時に世に出る予定
だったのですが、LongHorn待ちということで、次期
Orcasまで先送りになってしまったようです。
Object Spacesが予定通り進んでいれば、NHibernate
に対する反応もかなり違ったであろうことは確かです。
LongHornと言えばAvalonやIndigoですが、O/Rマッパー
が加わることで、「GUI」「WEBサービス」「データソース」
といったシステム開発の主要な要素が手続き的なスタンス
から宣言的なスタンスに移行することになります。XMLを
用いた宣言的なプログラミングについては先のエントリで
触れたように一長一短がありますが、一つのトレンドで
あることは間違いないようです。
