QuillとNhibernateの連携(1)


QuillとはSeasaa.Netの一部になるDIコンテナ。Seasaa.netにはS2DAO.NetがO/Rマッピングのツールとして付属していますが、S2DAO.Netを使用せずNHibernateを使用したいって人は・・・あまりいないかな?

しかし、NHibernateはFluet NhibernateとLinq対応で大変使いやすく、管理しやすいO/Rマッピングツールとして大進化しています。Fluet Nhibernateは設定ファイルとマッピングファイルを全てXMLでも属性(Javaでいうアノテーション)でもなくC#で書く事ができます。

これにより、設定ファイルとマッピングファイルがコンパイル前に型チェックや綴りチェックができるようになり、製造・管理が楽になります。これは流暢なインターフェイスによる内部DSLとしてかのマーチンファウラーがThoughtWorksアンソロジーで紹介しています。RubyのRailsではこの内部DSLをいろいろなところで採用しています。

また、これまでNHibernateの弱点としてSQLが書けないというものがありましたが、.NETでLINQを採用しこれに対応する事で、型チェックも可能な複雑なSQL(っぽいもの)も書けるO/Rマッピングツールとなりました。NHibernate独特のCriteriaやHQLを使用する事なく、.NET標準のLINQを使用する事で学習コストも下がり、かつ他にも応用できる(LINQはNHibernate以外でも採用されています。)ようになりました。

一方のDIコンテナQuillは属性ベースのDIコンテナです。DIコンテナでは有名どころでNSpringがありますが、こちらはXMLベースです。私自身の使用感ですが、DIツールではXMLベースより属性ベースの方が管理しやすいように感じます。なぜなら、DIはクラス単位(ファイル単位)ではなく、メソッド単位やプロパティ単位にも使用するためファイルでの管理はしにくく、属性を付けた方が管理しやすいように感じるからです。

かつてJAVAの世界では、MVCフレームワークからO/Rマッピングフレームワーク、DIコンテナまで全てXMLで管理していた時代がありました。これはXML地獄と言われ結局管理しにくくなるというジレンマに襲われていました。しかし、現在はMVCは規約ベース、O/Rマッピングも属性や内部DSLベースのツールが増えてきたため、DIコンテナのみXMLで管理するというやり方もOKだと思います。なにより、NSpringは強力なNHibernateの連携機能を備えています。

しかし、私の場合、先の理由によりQuillを使用しています。そこで問題となるのは、NHibernateとの連携です。NHibernateを単独で使用するのもありですが、せっかくのAOP機能を備えるQuillを使用しない手はありません。そこでNhiebernateのSessionとTransactionの管理をAOPでする方法を考えました。

その話を次回したいと思います。・・・そもそもなぜこれらのツールを使用するのかという話もそのうち。。。

1件のコメント

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です