model-view-controller - Zend 框架/MVC : What type of objects to push to the View?

Question

大家好 - 这里有一个关于 Zend Framework 或更好的关于 MVC 的问题:

我现在很长一段时间都在问自己，将业务对象(用户、团队等)推送到我的 View 是否是个好主意，或者只推送转储数据容器是否更好，例如数组到 View 进行渲染。

当将业务对象推送到我的 View 时，我在 View 和我的域模型之间有更紧密的耦合，但是， View 可以轻松地执行诸如 foreach($this->team->getUsers() as $user) { ... } 我个人觉得非常方便。

在哑数组中提供域模型数据对我来说看起来更健壮和灵活，但代价是 View 无法对真实对象进行操作，因此无法使用对象的方法访问相关数据。

你们是怎么处理的？

非常感谢，迈克尔

Answer 1

最好让您的 View 以面向对象的方式访问 Domain Model 对象，而不是使用 Controller 将 Model 数据转换为普通标量和数组。

这有助于防止 Controller 长得太胖。查看Anemic Domain Model反模式。 Controller 只需要知道要实例化什么 Model，将请求输入传递​​给该 Model，然后将 Model 注入(inject) View 脚本并进行渲染。请记住 a Domain Model is not a data-access class .

你也可以写成View Helpers封装域模型对象的通用呈现，以便您可以在多个 View 脚本中重复使用它。

您的 View 应该只以只读方式访问领域模型。 View 脚本不应尝试影响域模型的更改。

您还可以设计域模型来实现 ArrayObject或其他 SPL 类型，根据需要在 View 脚本中轻松使用 OO。

---

的确，一般来说，MVC 和 OO 设计的一大驱动动机是解耦。我们希望允许每一层在其他层被修改时保持不变。这些层只能通过它们的公共(public) API 进行交互。

ViewModel 是一种抽象模型的解决方案，这样 View 就不需要更改。我倾向于使用的是领域模型，它抽象了表设计等细节，并提供了一个更专注于业务而不是数据访问的API。因此，如果您的基础表发生变化， View 不必知道。

我希望如果领域模型发生变化，例如它需要提供一种新类型的属性，那么您的 View 很可能会发生变化，以便在 UI 中显示该新属性。

您选择哪种技术将一个层与其他层分离取决于您期望最频繁发生的更改类型，以及这些更改是否是真正独立的更改，或者它们是否需要对多个层进行更改。