Catalyst::Model::DBIC::Schemaを使った方がうれしいこと

ただ、CatalystのComponentとしても扱えるようにしておくと、例えばプラグインなどでCatalystのModelを参照している場合に楽できるというのはあるかなぁという気もします。

http://catalyst.g.hatena.ne.jp/dann/20080425/p1

ということをすると「そういうのはControllerで！」と全力でDISられるわけですが、それはさておき、あらたまって「ベースクラスにすることの意味」と言われると、configのマージを実装しなくてすむ（スクリプトなどから必要な部分のみ上書きできるし、Catalystアプリ上からはConfigLoaderで上書きできる）ことくらいしか大きな利点はないと思います。

言い方を変えれば、テスト用のDBへの接続部分を複数のテストで共有するためだけに専用のクラスをつくったり、あちこちに共通の設定を書き散らしたりする必要はない（デフォルトの設定はModel::DBIC::Schemaのなかに書いておけるので、本当に変える必要のある部分だけnewするときにハッシュリファレンスの形で渡してやればいい。Adaptorを使う場合、Adaptorの設定がクラスと、ごく一部の環境依存のものだけ（それ以外の設定はすべてPOPOの方でまっとうなデフォルトを用意している）ならいいですが、非環境依存の設定までAdaptorの設定として書いてしまうと、POPOを単体で使うとき、その設定もあらためて渡してやらないといけませんよね？）、と。

あとはまあ、DBIx::Class::Schemaを直接継承しているクラスに独自のメソッドを生やすより、DBIx::Class::Schemaのインスタンスを保持しているクラスにメソッドを生やした方が元の挙動を微妙に変えたいときとかに便利だとは思いますが、その程度。

追記：Catalyst::Authentication::Store::DBIx::Class::Userのように、$c->model('MyDB::Table')が（モデルオブジェクト自体ではなく）resultsetを返すことを期待しているような既存プラグイン／コンポーネント等で対応が簡単、というのもありますか。

もちろんもっと別の利点が出てくるようなベースクラスを独自実装することは可能だと思いますが、その辺、あまり度が過ぎると、今度は「先にその利点の部分だけ独立したモジュールにして公開しろ（Catalystをインストールしていないと使えないというのはもったいなさすぎる）」とDISられるかもしれません。

なんにしても、DBIC::Schemaを擁護しているのは、先日再利用性の点からDISったDBIC::Schema以前の遺物といっしょにしてほしくはないなあ（「ザクとは違うのだよ！ザクとは！」）というだけのことです。