ArkとData::Modelのサンプルアプリケーションとしてぼちぼち作っているSimpleLinksについて、Data::Modelでのリレーション(2) add_methodでリレーションを実装以後、一通りのテストと実装を行いました。まだ重複した処理が残っていたりして汚いのですが、改めて思うのは、手動で泥臭く実装するのは大変だということです。そもそも論を書いてしまえば、RDB的な物の考え方から抜け出せない私が自縄自縛に陥っているような気もしますが。
ともあれ、じゃああとはArkのModelと結婚させておしまいだね、と思って寝床で『モダンPerl入門』を読み返していると、p.102辺りで眠気が覚めました。
（前略）拡張機能を使いすぎるとそのORMの実装に詳しくない他の開発者達が全く手出しできないものになってしまいますし、（中略）業務上の効率を考えると何とか工夫を加えるにしてもその上のレイヤーで行うことをお勧めします。
なんだかData::Model::Mixinの使い方を間違えているような気が常々していたのですが、図星でした。
そもそもいやらしいのが、add_methodで行オブジェクトにメソッドを生やしつつも、その実装は（スキーマクラスの肥大化を防ぐために）個別のSimpleLinks::Schema::Mixin::*に丸投げしているという私の書き方です。
Data::Model::Mixin::FindOrCreateのような汎用的な機能や、Data::Model::Mixin::Queue::Q4Mのような（抽象でなく具象という意味で）低レベルな処理を扱うのには、なるほどmixinは便利でしょう。ですが、今回のようにadd_methodの実装をスキーマクラス（便宜的に表クラスとでも書きましょう）のクラスメソッドとして作成して、それをmixinしなければならないかというと、これは全然違いました。
そもそも現状でも使っているトランザクション（Data::Model::Transaction）を真っ当に使えば、別に外部で実装して問題になるわけではありません。
手動で泥臭くリレーションを実装するためには、行オブジェクト生成・更新・削除などにフックするのが簡単かつAPIも自然なので、行オブジェクトにメソッドを生やすこと自体は現状のままとしようと思います。つまり、スキーマクラスの一つ上のレイヤーであるサービス（API）クラスで実装すると、わざわざ$service->update_website($website)というような冗長な書き方になってしまいます（と思っています）ので、実装の投げ先だけSimpleLinks::Schema::Mixin以外のクラスに変えることによって、自然体で今のままの$website->updateにしたいという意図です。
ということで、少々実装を変えてからサンプルアプリケーションの解説を続けたいと思います。
コメントする