データアクセスレイヤの選択
拙作の.NETリッチクライアント向けフレームワークだが、今後はASP.NETでも使うことを考えている。
リッチクライアントはWindowsFormsをプレゼンテーションレイヤのターゲットとしてしたいたが、ASP.NETで使うということはWebFormsをプレゼンテーションレイヤのターゲットとして使えるようにする必要があるのは勿論のこと、リッチクライアントでは扱わなかったデータアクセスレイヤを用意しなくてはならない。
データアクセスレイヤで扱うアーキテクチャだが、Microsoftプラットホームといえども昔と違い非常に選択肢が多くなっている。(これもオープンソースのお陰だ)
現在考えている候補としては
.NETでは全てのデータアクセスレイヤのベースとなるミドルウェア的な部分に位置する物だが、これだけを使ってデータアクセイレイヤを構成することも当然可能(ADO.NET2.0の非接続型データソースは強力)
ただ、そのままで便利に使うには大抵Visual Studio 2005の助けが必要となるため、(MONOも含めて)それが嫌なら後述する他のフレームワークと一緒に使うことになる。
ご存知O/Rマッピングフレームワークの雄であるHibernateの.NET版。既に本家Hibernateに馴染みがあるのであればこれに決めても良いのだが、幸い?にも殆ど使ったことが無いので早々に外れるか。
これも著名なO/Rマッピングフレームワーク。NHibernateとは違い、良くも悪くもSQLを意識して使うのが特徴であり、それが逆にシンプルで私はHibernateよりこちらのほうが好きである。
国産DIコンテナの雄であるS2Container.NETのデータアクセスレイヤ。アノテーションベースのO/Rマッピングを可能としており、できるだけ設定ファイルを無くそう、シンプルに行こうというポリシは素晴らしい。また、iBATIS.NET同様にSQLを外部ファイルでそのまま扱うことができるのも好みだ。
拙作のフレームワークは元々S2Container.NETと同様にSeasar2の設計を使わせて頂いており、それを考えるとS2DAO.NET同様の実装を使うのが良いかもしれない。
- その他
以前に紹介したThe CodeProjectの記事のように、軽量なO/Rマッピングフレームワークをスクラッチで用意する案。巷のO/Rマッピングフレームワークはどれも機能豊富であり、当初はここまでの機能は必要無い場合は自分で用意したほうが良い。また、現在のアセンブリ構成をこれ以上変えたくない(アセンブリを増やしたくない)ということになれば、自ら実装するしかない。また、既にDAOフレームワークがある場合はそれとの整合性のために、やはり自ら実装することになるだろうか。
とまあ、いろいろな妄想と共に検討中である。現状は業務で使うSQLが最初から解っているのとシンプルさでiBATIS.NET、アノテーション重視であればS2DAO.NET。次点は内製かな。
追記
ASP.NETにおけるデータアクセイレイヤ、O/Rマッピング技術に関しては山田さんが@ITに寄稿している記事が解り易くてお勧めだ。
ASP.NETで実践するO/Rマッピング（NHibernate編）
ASP.NETで実践するO/Rマッピング（iBATIS.NET編）
