Hatena::Groupcatalyst

dann@catalyst このページをアンテナに追加 RSSフィード

2008-04-25

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

RE:Catalyst::Component(Catalyst::Model::DBIC::Schema)を使った方がうれしいこと - dann@catalyst を含むブックマーク はてなブックマーク - RE:Catalyst::Component(Catalyst::Model::DBIC::Schema)を使った方がうれしいこと - dann@catalyst RE:Catalyst::Component(Catalyst::Model::DBIC::Schema)を使った方がうれしいこと - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/charsbar/20080425/1209129640

ということをすると「そういうのはControllerで!」と全力でDISられるわけですが、

うーん、自分が考えている話とはずれてるようなので書いておきます。

既存のAuthentication系のPluginで$c->modelでユーザークラスを参照してたりしますよね。あれを使うためには、「CatalystのModel」を用意してやる必要があると。そうしたときに、POPOのUserのモデル作るだけだと、Catalyst::Model::Adaptorでラップして、Catalystのモデルにしてやる必要がありますよね。で、Catalyst::Model::DBIC::Schemaをベースクラスに使えば、その手間を省けるのかなと思ったわけです。

要するに、Catalyst下では、Catalystのモデルとしても扱いつつ、Catalyst外(内でも)ではPOPOっぽくも扱えるというメリットもあるのかなと思ったわけですが、charsbarさんがそう考えているわけではないというとこですかね。

AuthenticationもPlugin使うのではなくて、「Controllerで」と言われると、charsbarさんの発言の意味を多分理解していないのだろうなぁとは思います。

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

Catalyst::ComponentにしておくとConfig周りの恩恵を受けられるってことですかね。DBICのベースクラスとしての利点よりも。

Configのマージ処理とWAF下で動作するときにPOPOのモデルにConfigをinjectするための仕組みを汎用化すれば、モデルを完全に切り離せるのかなって気がしました。

少し先が見えた気がします。

Catalyst::Model::DBIC::Schemaに依存していても困らないかも?

Catalyst::Model::DBIC::Schemaに依存していても困らないかも? - dann@catalyst を含むブックマーク はてなブックマーク - Catalyst::Model::DBIC::Schemaに依存していても困らないかも? - dann@catalyst Catalyst::Model::DBIC::Schemaに依存していても困らないかも? - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/charsbar/20080425/1209053541

id:charsbarさん、id:typesterさん、どうもありがとうございます。

Catalyst::Model(要するにCatalyst::Component)に依存しているといっても、実質はCatalystという名前がついてるだけで、WAFというレベルでの依存じゃないんだから、ベースクラスに使ったっていいんじゃないか?っていう話だと理解しました。名前にだまされてるっていうのは、こういう話なのかなと。

それで、Catalyst::Model::DBIC::Schemaを継承したクラスで、Catalyst依存にならないようにだけすれば、WAFに依存すると言うものではないので、いいんじゃないかという話なのかなぁと。

後は、継承したクラスをnewしたときに設定されるschemaのインスタンスを使えば、POPOも同然じゃないかって話なのかなと思いました。

あまりこれは考えていなかったんですが、案外これでもいいのかなぁという気もしました。Catalyst::Componentに依存することの気持ち悪さはありますが、実質上の大きな問題は確かにないわけなので。

ただ、POPOとしてだけ扱いたいというときに、schemaのインスタンスを生成して保持しといても大差ないように思えるので、ベースクラスにすることの意味がどれだけあるのかは、よくわかりませんでした。

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

Catalyst::Componentがベースクラスになっていることに、微妙に違和感はあるものの、Catalystありきという前提であれば、実用上はそれでも問題はないので、charsbarさんがDBIC::Schema isn't so bad...という表現をされているのかなぁという気もするのですが。

# RailsライクにMember->findのような形で扱いたいというのは、DBICの話で、Catalystの話とは関係ない話なので、ここではとりあえず触れずに。

charsbarcharsbar2008/04/26 00:23Authentication::Store::DBIx::Classは、::Userのnewを見ればわかる通り、

resultset => $c->model($config->{'user_class'})

という形で$c->modelがresultsetを返すことを期待していますので、そもそもACCEPT_CONTEXTが埋め込まれているModel::DBIC::Schemaを使うのが大前提です(Adaptorとかでも頑張ればできるでしょうが……)

danndann2008/04/26 02:34orz.. そう考えると、何となくModel::DBIC::Schema自身をベースクラスにすることの意味もある気がしますね。

または、POPOモデルだけを使えるようにするには、$c->model($config->{'user_class'})と参照しているところをオーバーライドできるようにしておいて、サブクラスでresultsetを返せるようにしておくんですかね(Schemaから)。なんだか、この話は前に日記に書いた気がしますね。

悩ましいところですが、Catalystを使う分だと、DBIC依存部分はModel::DBIC::Schema使ったほうが結局楽なのかなぁという気もしてきました。もうちょっと考えてみます。

トラックバック - http://catalyst.g.hatena.ne.jp/dann/20080425