Hatena::Groupcatalyst

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

2008-03-06

DBにしか入れないデータでも、DBICのモデルにロジックを置くのは悪なのか?

22:26 |  DBにしか入れないデータでも、DBICのモデルにロジックを置くのは悪なのか? - dann@catalyst を含むブックマーク はてなブックマーク -  DBにしか入れないデータでも、DBICのモデルにロジックを置くのは悪なのか? - dann@catalyst  DBにしか入れないデータでも、DBICのモデルにロジックを置くのは悪なのか? - dann@catalyst のブックマークコメント

yappoさんのBlogからのリンクの記事を読んでみても、自分が疑問に思っていることは、やっぱり解決していないなぁと思っています。

自分が疑問に思っているのは、

DBにしか入れないデータで、複数のモデルにまたがらないロジックでも、DBICSchemaにロジックを置くのは悪なのか?」

ということでです。

僕は、データを知っている人だけが、そのデータに対する振る舞いを定義するべきなんじゃないかと思うわけです。

その点、複数のモデル(データ)にまたがるロジックは、一つのDBICのモデルに押し込むのは変で、Serviceクラス(宮川さんが書いているCクラスに書くのは自然なことなんだと思っています。

こうしたときに、DBICのモデル(テーブルに対応)に固有のロジックは、DBICのモデルに直に書くのがいいんじゃないかと思っていて、何でそこに書いていけないのか?と思うのです。これに対する解は、どの記事にも書いていないように思いました。(自分の理解が正しければ、RailsのAcriveRecordは、まさにDBICのモデルに直にロジックを書く形なんじゃないかと思っています)

これに対する予想される解は、以下のことが考えられます。

  • DBICという一つのORマッパに依存してしまうこと
  • モデルがDBに依存することで、テスタビリティが下がること

一つ目の解である、「ORマッパへの依存」については、自分は問題ないと思っているというのは前の記事で書きました。開発後にORマッパを以降することがないからです。また、ORマッパの差異を吸収するラッパを書いて、それを使うというのは、現実的ではないと思っているからです。

二つ目の解である、テスタビリティが下がることについては、解があるんじゃないかという記事を書きました。Rails界隈のBlogをざっとみた限りでは、以下の記事は自分が思っている解に近いものだと思いました。簡単にまとめると、ActiveRecordの一部メソッドをStubでつくり、カラムのデータをテスト用に作るというものです。

http://blog.jayfields.com/2006/12/rails-activerecord-unit-testing.html

要するにORマッパレベルでStubを作ることで、DBへの依存を断ち切るわけです。多分、DBICでも同じことができるんじゃないかと思っています。簡単にStubが作れれば、テスタビリティが下がるという問題もなくなってしまいます。

DBなしでもUnitTestができるわけで、これも問題になりません。UnitTestレベルでは、DBに依存しないテストが簡単に作れそうです。

そう考えると、やっぱりどうしても、DBICのモデルにロジックを記述することの問題点というのがわからないのです。何が問題になるのだろう。これは、ActiveRecordのモデルにロジックを書くのは、何が問題なのかっていうことの問題と同じなんじゃないかと殆ど同じだと思っています。

このDBICのモデルにロジックを置く事に、何か問題(開発効率上、テスタビリティなどなど)があるのであれば本当に教えてもらいたいなぁって思う。

これで問題があれば、結局のところJava界隈で話されていたアーキテクチャに戻るということも当然あるとは思っているんですが、今のところこれといった問題がないように思えてしまうんですよね。Javaでは、DAOを切り離すしか解がなかったと思うので、アーキテクチャとして、ORマッパのモデルにビジネスロジックを置くという解がそもそもなかったと思います。だから、前のエントリで書いた、レイヤを切り離すアーキテクチャは正しかったんじゃないかと思います。ただ、Dynamic Languageでのアーキテクチャには、別の解があるんじゃないかと思っていて、それこそが自分の疑問点の始まりだったりします。

# DBICのモデルにロジックを置くのは間違いなのか?というのは、ActiveRecordのモデルにロジックを置くのは間違いなのか?と読み替えてもらってもよいのではないかと思います。

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