初めての CRUD アプリケーションを作成しようとしていますが、getter と setter が分離されたオブジェクトを使用する必要があるかどうかわかりません。
以下を含むモデル構造を持つZend Framework クイック スタート チュートリアルがあるとします。
ドメイン オブジェクト (Zend クイック スタート チュートリアルに示されている) がゲッターとセッターのみで構成されている場合、それはアンチパターンですか? ある意味、トランザクション スクリプトでドメイン オブジェクトを不必要に分割しているのでしょうか。
お知らせ下さい。
Anemic Domain Model は、真の Domain Model (別名 Domain Driven Design の Domain Model) を構築しようとしていて、状態のみで動作のないエンティティで終わる場合にのみ、アンチ パターンです。
単純な CRUD アプリケーションの場合、特に作業を非常に簡単にするフレームワークがある場合は、貧血ドメイン モデルがおそらくベスト プラクティスです。
Anemic Domain Modelに関する Martin Fowler の記事と、Greg Young の記事 を参照してください。
ドメイン オブジェクトは、ソフトウェアのビジネス ロジックから分離されます。これは手続き型プログラミングの重要な考え方です。
ただし、一部の開発者はこのパターンをアンチパターンの候補と見なしており、効果のないプラクティスである可能性があります。
実際、あなたはデメリットを考えることができます
考慮すべき最も興味深い点は、ドメイン モデルのオブジェクトは常にその正確性を保証できないということです。それらの突然変異は別々の層で起こるからです。
ZendフレームワークでもCRUDアプリケーションに取り組みました。ロジックとデータの明確な分離は非常に優れていますが、進行するにつれて、レイヤーとマッパーの量がどんどん大きくなっていることに気付きます。できる限りコードを再利用し、重複を避けるようにしてください。