やあみんな - これはZend FrameworkまたはMVC全般に関する質問です:
ビジネス オブジェクト (ユーザー、チームなど) を自分のビューにプッシュするのが良い考えなのか、配列などのダンプ データ コンテナーをレンダリング用のビュー。
ビューにビジネス オブジェクトをプッシュするとき、ビューとドメイン モデルの間の結合がより緊密になりますが、ビューは foreach($this->team->getUsers() as $user) { ... のようなことを簡単に実行できます。個人的にはとても便利だと思います。
ドメインモデルデータをダム配列で提供することは、より堅牢で柔軟に見えますが、ビューが実際のオブジェクトを操作できないため、オブジェクトのメソッドを使用して関連データにアクセスできないというコストがあります。
どうやってそれを処理しますか？
どうもありがとう、マイケル
コントローラーを使用してモデル データをプレーンなスカラーや配列に変換するのではなく、ビューがオブジェクト指向の方法でドメイン モデル オブジェクトにアクセスするようにすることをお勧めします。
これにより、コントローラーが肥大化するのを防ぐことができます。貧血ドメイン モデルのアンチパターンを参照してください。コントローラーは、どのモデルをインスタンス化するかを知る必要があるだけで、リクエスト入力をそのモデルに渡し、そのモデルをビュー スクリプトに挿入してレンダリングします。ドメイン モデルはデータ アクセス クラスではないことに注意してください。
ビュー ヘルパーを記述して、ドメイン モデル オブジェクトの一般的なレンダリングをカプセル化することもできるため、複数のビュー スクリプトで再利用できます。
ビューは、読み取り専用の方法でのみドメイン モデルにアクセスする必要があります。ビュー スクリプトは、ドメイン モデルに変更を加えようとしないでください。
View スクリプトで OO を簡単に使用できるようにするために、必要に応じて、ArrayObjectまたはその他の SPL タイプを実装するようにドメイン モデルを設計することもできます。
確かに、MVC と OO 設計全般を推進する大きな動機は、デカップリングです。他のレイヤーが変更されても、各レイヤーは変更されないようにしたいと考えています。公開 API を介してのみ、レイヤーが対話します。
ViewModel は、ビューを変更する必要がないようにモデルを抽象化する 1 つのソリューションです。私がよく使用するのは、テーブル設計などの詳細を抽象化し、データ アクセスよりもビジネスに重点を置いた API を提供するドメイン モデルです。したがって、基になるテーブルが変更された場合、ビューはそれを知る必要はありません。
たとえば、新しいタイプの属性を提供する必要があるなど、ドメイン モデルに変更があった場合、UI にその新しい属性を表示するために、View が変更されている可能性があります。
あるレイヤーを他のレイヤーから分離するためにどの手法を選択するかは、最も頻繁に発生すると予想される変更の種類と、これらの変更が本当に独立した変更になるかどうか、または複数のレイヤーへの変更が必要になるかどうかによって異なります。
「標準的な」アプローチは、コントローラーでモデルを完全に準備し (たとえば、ユーザーを含むすべてのチームを取得)、それをビューに送信して表示することですが、それに縛られることはありません。データ構造は、配列、ArrayObject、またはカスタム クラスなど、適切と思われるものであれば何でもかまいません。
私は Zend フレームワークを使用していないので、これは一般的な MVC に対応しています ViewModel パターンを見てください。
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx
私は.Net MVCの観点から来ていますが、概念は同じだと思います。
基本的に以下のようにコントローラーですべてのビューレンダリングを行います
したがって、私のチームはお互いに干渉することなく各部分に取り組むことができます。これにより、プロジェクトに情報セキュリティが追加されます。つまり、変数/オブジェクト仕様によってのみ通信するすべての作業コードを誰も取得できなくなります。