Zend Framework / MVC：将什么类型的对象推送到视图？
大家好 - 这里有一个关于 Zend Framework 或者更好的关于 MVC 的问题：
我现在安静地问自己很长一段时间，将业务对象（用户、团队等）推送到我的视图中是否是一个好主意或如果将转储数据容器（例如数组）推送到视图进行渲染会更好。
当将业务对象推送到我的视图时，视图和域模型之间的耦合更加紧密，但是，视图可以轻松执行类似 foreach($this->team->getUsers() as $user) { 的操作。 .. } 我个人觉得这非常方便。
在我看来，在哑数组中提供域模型数据看起来更加健壮和灵活，但代价是视图无法在真实对象上操作，因此无法使用对象的方法访问相关数据。
你们怎么处理？
非常感谢， 迈克尔
Hey guys - here's a question on Zend Framework or better on MVC in general:
I am asking myself for a quiet a long time now, if it is a good idea to push business objects (User, Team, etc.) to my views or if it would be better just to push dump data containers such as arrays to the view for rendering.
When pushing business objects to my view I have a much tighter coupling between the views and my domain model, however, the view could easily do things like foreach($this->team->getUsers() as $user) { ... } which I personally find very handy.
Providing domain model data in dumb arrays to me looks more robust and flexbile but with the costs of that the view cannot operate on real objects and therefore cannot access related data using object's method.
How do you guys handle that?
Thanks much,
Michael
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
最好让视图以面向对象的方式访问域模型对象，而不是使用控制器将模型数据转换为普通的标量和数组。
这有助于防止控制器变得太胖。请参阅贫血域模型反模式。控制器只需要知道要实例化什么模型，将请求输入传递给该模型，然后将模型注入视图脚本并渲染。请记住，域模型不是数据访问类。
您还可以编写 View Helpers 来封装通用渲染域模型对象，因此您可以在多个视图脚本中重复使用它。
您的视图应该仅以只读方式访问域模型。视图脚本不应尝试影响域模型的更改。
您还可以设计域模型来实现 ArrayObject 或其他 SPL 类型，根据需要在视图脚本中轻松使用 OO。
确实，MVC 和 OO 设计的一大驱动动机通常是解耦。我们希望允许每一层在修改其他层时保持不变。各层仅通过其公共 API 进行交互。
ViewModel 是一种抽象模型的解决方案，这样视图就不需要更改。我倾向于使用领域模型，它抽象了表设计等细节，并提供更专注于业务而不是数据访问的API。因此，如果您的基础表发生更改，视图不必知道它。
我希望如果域模型发生变化，例如它需要提供一种新类型的属性，那么您的视图很可能会发生变化，以在 UI 中显示该新属性。
您选择哪种技术将一层与其他层解耦取决于您期望最频繁的更改类型，以及这些更改是否是真正独立的更改，或者它们是否需要对多个层进行更改。
It's better to make your View access a Domain Model object in an object-oriented manner, instead of using the Controller to convert Model data into plain scalars and arrays.
This helps to keep the Controller from growing too fat. See the Anemic Domain Model anti-pattern. The Controller only needs to know what Model to instantiate, passes the request inputs to that Model, and then injects the Model into the View script and renders. Keep in mind that a Domain Model is not a data-access class.
You can also write View Helpers to encapsulate a generic rendering of a Domain Model object, so you can re-use it in multiple View scripts.
Your View should accesses the Domain Model only in a read-only manner. View scripts should not try to effect changes to the Domain Model.
You can also design your Domain Model to implement ArrayObject or other SPL type(s), as needed to make OO usage easy in the View script.
It's true, a large driving motivation of MVC and OO design in general is decoupling. We want to allow each layer to remain unchanged as the other layer(s) are modified. Only through their public APIs do the layers interact.
The ViewModel is one solution to abstract the Model so that the View doesn't need to change. The one I tend to use is Domain Model, which abstracts the details of table design, etc. and supplies an API that is more focused on the business rather than the data access. So if your underlying tables change, the View doesn't have to know about it.
I would expect that if there's a change to the Domain Model, for instance it needs to supply a new type of attribute, then it's likely that your View is changing anyway, to show that new attribute in the UI.
Which technique you choose to decouple one layer from the others depends on what types of changes you expect to be most frequent, and whether these changes will be truly independent changes, or if they will require changes to multiple layers anyway.
“标准”方法是在控制器中完全准备模型（例如获取所有团队，包括用户），然后将其发送到视图进行演示，但您不受此限制。数据结构可以是您想要的任何内容：数组、ArrayObject 或自定义类 - 任何您认为合适的内容。
The "standard" approach would be to completely prepare the model in the controller (e.g. fetch all teams, including users) and then send that to the View for presentation, but you are not bound by that. The data structures can be whatever you want it to be: Array, ArrayObject or custom Classes - anything you deem appropriate.
我不使用 Zend 框架，所以这是对一般 MVC 的回应。看看 ViewModel 模式。
http: //www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx
我是从 .Net MVC 的角度出发的，但是我相信这些概念是相同的。
I dont use Zend framework, so this is in repsonse to the general MVC Have a look at the ViewModel pattern.
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx
I'm comming from a .Net MVC point of view but I believe the concepts will the same.
我将在控制器中进行所有视图渲染，基本上如下所示
因此我的团队可以在不互相干扰的情况下处理每个部分，这也为项目添加了一些信息安全性，即没有人可以检索所有内容他们仅通过变量/对象规范进行通信的工作代码。
I will do all my view rendering in the controller bascially like below
So my team can work on each part without interrupting each other, this also add some information security to the project i.e no one can retrieve all the working code they only communicate by variables/object spec.