ドメイン モデルとデータ マッパーが OOP スノブの選択であることは知っています (Martin Fowler が自称するように、補完的な方法で「スノブ」を使用します) - ただし、ファウラーでさえPOEAA で次のように述べています
「Active Record は、複雑すぎないドメイン ロジックに適しています...」
製品と請求書のドメイン モデルが単純で、モデル化するテーブル/オブジェクト/概念が多すぎず、関係もそれほど複雑ではありません。では、これは Active Record の適切な使用例でしょうか?
Fowler はまた、アクティブ レコードは行データ ゲートウェイに似ていると述べていますが、アクティブ レコードにはドメイン ロジックがあるという違いがあります。
これが Active Record の有効な使用例であり、Zend が Row Data Gateway を提供しているため、(単純にテーブル名を追加するのではなく) これらのオブジェクトをインテリジェントに拡張するソリューションは、Zend Framework を使用して Active Record オブジェクトを作成する良い方法のように思えます。 . 実際、その概念はこの SO answer で説明されています。これは、Zend Framework 内に Active Record を実装する方法として受け入れられますか?
もちろん、その質問に対する最も一般的な回答はBill Karwin (Zend の Db 実装に取り組んだ)によるもので、 orを使用しないことを推奨しています (少なくとも私はそう読みました)。Zend_Db_Table
Zend_Db_Row
問題のドメイン モデルがより複雑になった場合、Data Mapper ソリューションに移行したいという希望を完全に受け入れます。私はさまざまな ORM/DataMappers を見てきました (問題のドメイン モデルだけでなく、最近 OOP 設計パターンについて詳しく読んでいます) が、いくつかの点では多すぎるように思えます。