This is Yugui (Yuki Sonoda)'s Typepad Profile.
Join Typepad and start following Yugui (Yuki Sonoda)'s activity
Join Now!
Already a member? Sign In
Yugui (Yuki Sonoda)
Saitama, Japan
A web programmer. The release manager of Ruby 1.9 series. MtF-TS.
Interests: software development, cycling
Recent Activity
追記を拝見するには、この記事は「active recordパターンの限界」と題するべきだったのではないでしょうか。そもそも"Pattern of Enterprise Application Architecture"あるようにこのパターンは「構築が容易であり、また理解もしやすい」代償としてそのままでは複雑なロジックを扱いづらく、「トランザクションスクリプトに保持され」への一部分離を必要とすることがある、そういうものです。 ソフトウェアの成長の中で分離のタイミングを見極め損なうとactive recordで扱いづらいロジックがコントローラーに流出する虞があるというのはその通りです。active recordの実装たるActiveRecordもその特徴と制約を受け継いでいます。 「この手の基本原理の定義を変えてしまうことはとても混乱を招くのでやめた方が良い」まったくその通りです。「データベースのテーブルを単にオブジェクトの形に抽象化しただけのものであり、そこにはビジネスロジックは一切含まれていない」というのはactive recordではありません。まともなRails入門書でもそのように開発を進めて見せているものはないはずです。「ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装」もまたこのパターンにおける最初の選択肢ではありません。トランザクションスクリプトに分離する前にactive recordオブジェクトそれ自体にロジックを組み込むことを検討すべきであり、それこそがactive recordの特長です。 また、こういった問題に直面したエンジニアがおおもとをきちんと理解していないときにロジックをcontrollerに流出させてしまう傾向は確かにあります。しかしこの問題に対して、active recordパターンはそれほど悪い選択肢でしょうか。既に追記で触れられているように、DAOを採用してサービスレイヤの挿入を意図したところで、分かっていない開発者はトランザクションスクリプトをcontrollerに混ぜ込むするだけです。少なくともactive recordには、サービスレイヤの分離を必要としない規模で実装をシンプルに保てるという利点と、それ自体の歴史的経緯を辿ってモデル層の責務の重要性についての議論に到達するポインタの役割を果たすという利点はありそうです。 そうしてみるとこれはactive recordパターンの問題ですらなく、特有の注意点でもなく、実はこの記事は「ドメインモデル貧血症」と名付けるべきかもしれませんね。 * http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel active recordパターンの実装がドメインモデル貧血症を引き起こしているとしたら皮肉な話ですね。