国内では微妙な立ち位置に

ずいぶん間が空いてしまいましたが，今回はデータベース話の3回目として，DBICことDBIx::Classについてまとめてみます。DBICは，海外ではMooseやCatalystと並ぶモダンPerl界の三種の神器のひとつとしていまも広く宣伝されていますが，国内では，当初こそClass::DBIからの乗り換えを強力に推進する流れが見られたものの，最近ではあまり名前を聞くこともなくなり，むしろDBICからの脱却が潮流になっているかの印象を受けることさえあります。いったい何がどうなっているのか，例によって歴史を追いかけながら見ていきましょう。

もともとはオブジェクトを永続化するためのもの

DBICの立ち位置を理解するには，まずはその先駆けとなったClass::DBIがどういうものであったかを理解しておく必要があります。

連載第36回でも紹介したように，マイケル・シュワーン（Michael Schwern）氏が1999年12月にリリースしたClass::DBIは，その前年にリリースされたDBIx::Recordsetなどと並んで，DBIの拡張としては最初期のものにあたります。DBIx::Recordsetや，やや遅れて登場したDBIx::Abstractは，インタフェースこそ抽象化されて生のSQLを書く必要はなくなったものの，取り出したデータは生の配列やハッシュのリファレンスに格納されていましたが，Class::DBIは，ちょうどこの時期Perlのオブジェクト指向プログラミングが本格化してきたという事情もあって（ダミアン・コンウェイ氏の『Object Oriented Perl（オブジェクト指向Perlマスターコース⁠）⁠』が出版されたのは1999年8月（邦訳は2001年）のことでした⁠）⁠，インタフェースの改善にとどまらず，取り出したデータもオブジェクトになっているのがひとつの特徴でした。

もう少し正確にいうと，初期のClass::DBIは，連載第19回で取り上げたKiokuDBと同じく，あくまでもオブジェクトを永続化するための手段としてデータベースを使っていただけで，主眼はあくまでもオブジェクトにありました。KiokuDBと違ってテーブルとクラス，カラムとアクセサ／ミューテータは一対一で対応していましたが，Class::DBIを継承するパッケージに書くのはあくまでもオブジェクトの内部データをいじるためのアクセサ／ミューテータであって，テーブルのスキーマそのものではありませんでしたし，背後にあるIma::DBIを通じて生のSQLを発行する仕組みこそあったものの，通常は極力SQLを意識させないようになっていました（実際，生のSQLを発行する場合はDBIとほぼ同レベルのことしかできなかったため，Class::DBIのうまみはほとんど享受できませんでした⁠）⁠。名前こそDBIとついていましたが，これはあくまでもクラスにDBIとの連携機能を追加したもの，という位置づけであって，既存のデータベースを自由に操るためのものではなかったわけです。

もっとも，たとえばウェブのフォームから送られてきたデータをそのまま保存したいだけなら，リレーショナルデータベースの力はそれほど必要としません。リレーショナルデータベースの皮をかぶったカード型（簡易）データベース的な使い方しかしていないのであれば，Class::DBIに用意されている基本的なメソッドだけですべての処理をまかなうこともできました（実際，Class::DBIの初期の実装はDBD::CSVでテストされていました。想定されていた用途はそれで足りるくらいのものだったわけです⁠）⁠。

ただし，Class::DBIはあまり作り込まれていなかった分，拡張の余地もたくさんありました。2001年6月にトニー・ボウデン（Tony Bowden）氏がClass::DBI::mysqlと題してMySQL用の拡張をリリースしたのを皮切りに，宮川達彦氏のClass::DBI::ExtensionやClass::DBI::Replicationなど，Class::DBIとデータベースの連携を強化するモジュールが少しずつ増えていきます。

この傾向は2001年9月にボウデン氏がメンテナを引き継いでからはさらに顕著になりました。もともとは「Simple Object Persistance（簡単なオブジェクトの永続化⁠）⁠」と銘打たれていたタイトル行が「Simple Database Abstraction（簡単なデータベースの抽象化⁠）⁠」に変わったのは2002年11月にリリースされた0.90でのことでしたが，それと前後してリレーションまわりの対応が大幅に強化されていますし，カラムの型制約を指定したり，複数の条件をくみあわせたフィルタリングができるようにもなりました。最初にデータベースありきという流れのひとつの象徴として，2002年8月には池邉智洋氏のClass::DBI::Loaderというデータベースのスキーマから自動的にクラス定義を行ってくれるモジュールも登場しています。

その後もユーザ数の増加にともなって次々に新しいモジュールが登録され，2004年頃までにClass::DBIはこの分野におけるデファクトスタンダードとして，CPANでもっとも人気のあるモジュールのひとつに数えられるようになっていました。2004年1月に登場したApache::MVC，のちのMaypoleというウェブアプリケーションフレームワークでは，ビューを司るTemplate Toolkitと並んで，Class::DBI(::Loader) がモデル層を抽象化する重要なパーツとなっています。

NEXTの時代

Maypoleは，よくある管理画面のように，お決まりのフォームにお決まりのデータベース，テンプレートも基本的な構造はほとんど同じ，というものを，お決まりのモデル，お決まりのテンプレートエンジンを使ってさくっと仕上げる場合にもっとも力を発揮するように書かれていました。原作者であるサイモン・カズンズ（Simon Cozens）氏は，Perl Foundationからの助成金を受けて集中的に開発できたという事情もあって，2004年7月にリリースした1.7で一通りの機能は揃ったと判断し，事実上の開発終了を宣言するのですが，そのあとを継いでメンテナになったゼバスティアン・リーデル（Sebastian Riedel）氏が，保守管理だけしてくれればというカズンズ氏の意向に反して，Maypoleに連載第2回でも紹介したNEXTを組み込んでより汎用的な，拡張性の高いものにしようとしたため，カズンズ氏らから「その変更は適切なデフォルトを重視するMaypoleの本質を変えてしまう」と猛反発を受け，改造版のMaypoleにCatalystという別の名前をつけて独立せざるをえなくなる，という事件が起こります。その騒動の余波をまともにかぶったのがClass::DBIでした。

Class::DBIはもともとそれほど複雑なことができるようには作られていなかったため，銘々がプラグインを書いて必要な機能を追加していたのは先にも書いた通りですが，Class::DBIは多重継承をよしとする時代の産物であったため，多いときでは本体だけで5つものクラスを継承していたうえ，初期の拡張のなかには機能を追加するために本体を継承するものもあれば，継承関係は無視して特定のメソッドをミックスインするものもある，という具合で，利用したいプラグインの数が増えていくにつれ安全確実な機能拡張がむずかしくなる，という問題が知られていました。

ボウデン氏がメンテナに就任した理由のひとつにはこの多重継承の軽減があったそうで，実際，2001年10月にリリースされたバージョン0.35ではフック（トリガ）機構を導入して継承に頼らない拡張を可能にしたほか，2004年4月にリリースされた0.96で一通りの機能追加が終わったあとは内部をさらにリファクタリングしてプラグインを書きやすくする計画もあったようなのですが，こちらはなかなか実現されず，結果的には1年以上もリリースが滞ることになってしまいます。そのため，Catalystと同じくらい柔軟な拡張性や頻繁な更新を求めるリーデル氏らと，安定性を重視し過剰な拡張性は不要とするボウデン氏らとの間で意見の衝突が目立つようになり，最終的には業を煮やしたマット・トラウト（Matt S Trout）氏がClass::DBI::Sweetというベタープラクティス集的なパッケージに続いて（2005年5月⁠）⁠，実験的なプロジェクトとして，Class::DBIとの互換性を維持しつつもNEXTを使って拡張性を高めたDBIx::Classの開発を始めます（2005年8月⁠）⁠。

そのこと自体は多重継承と委譲のどちらがすぐれているかという興味深い議論の成果でもあったのですが，ちょうどこのときリーデル氏の一連の発言にうんざりしたボウデン氏が冷却期間をおくためメーリングリストやWikiを閉鎖するという事件が起こったこともあって，Catalyst界隈を中心にClass::DBI(::Sweet) からDBICへの乗り換えが始まります。リーデル氏はやがてCatalystチームからも追われて，トラウト氏を中心とした集団指導体制に移ることになるのですが，その頃にはもうCatalystとDBICはほとんど不可分のペアとして宣伝されるようになっていました。国内でもこの頃はまだClass::DBI時代のバッドノウハウを解消するものとしてDBICへの好意的な発言がよく見られたものです。