嘿伙计们——这里有一个关于 Zend 框架的问题，或者一般来说关于 MVC 的问题：
我现在问自己很长时间了，将业务对象（用户、团队等）推送到我的视图是否是个好主意，或者将转储数据容器（如数组）推送到我的视图是否更好视图进行渲染。
当将业务对象推送到我的视图时，视图和域模型之间的耦合要紧密得多，但是，视图可以轻松地执行诸如 foreach($this->team->getUsers() as $user) { ... } 我个人觉得非常方便。
在我看来，以哑数组形式提供域模型数据看起来更加健壮和灵活，但代价是视图无法对真实对象进行操作，因此无法使用对象的方法访问相关数据。
你们是怎么处理的？
非常感谢，迈克尔
最好让您的 View 以面向对象的方式访问 Domain Model 对象，而不是使用 Controller 将 Model 数据转换为纯标量和数组。
这有助于防止 Controller 长得太胖。请参阅贫血域模型反模式。控制器只需要知道要实例化什么模型，将请求输入传递给该模型，然后将模型注入视图脚本并渲染。请记住，域模型不是数据访问类。
您还可以编写View Helpers来封装域模型对象的通用渲染，因此您可以在多个 View 脚本中重用它。
您的视图应该仅以只读方式访问域模型。视图脚本不应尝试对域模型进行更改。
您还可以根据需要设计域模型以实现ArrayObject或其他 SPL 类型，以便在 View 脚本中轻松使用 OO。
确实，MVC 和 OO 设计的一大驱动动机是解耦。我们希望允许每一层在修改其他层时保持不变。只有通过它们的公共 API，这些层才能进行交互。
ViewModel 是一种抽象模型的解决方案，以便视图不需要更改。我倾向于使用的是Domain Model，它抽象了表设计等细节，并提供了一个更专注于业务而不是数据访问的API。因此，如果您的基础表发生更改，视图不必知道它。
我希望如果域模型发生变化，例如它需要提供一种新类型的属性，那么您的视图很可能会发生变化，以在 UI 中显示该新属性。
您选择哪种技术将一层与其他层解耦取决于您期望最频繁的更改类型，以及这些更改是否将是真正独立的更改，或者它们是否需要对多个层进行更改。
“标准”方法是在控制器中完全准备模型（例如获取所有团队，包括用户），然后将其发送到视图进行演示，但您不受此约束。数据结构可以是任何你想要的：Array、ArrayObject 或自定义类——你认为合适的任何东西。
我将在控制器中完成所有视图渲染，基本上如下所示
所以我的团队可以在不中断彼此的情况下处理每个部分，这也为项目增加了一些信息安全性，即没有人可以检索他们仅通过变量/对象规范通信的所有工作代码。
我不使用 Zend 框架，所以这是对一般 MVC 的回应。看看 ViewModel 模式。
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx
我来自 .Net MVC 的观点，但我相信这些概念是相同的。