Zend Framework / MVC: какие типы объектов нужно отправить в View?

Question

Привет, ребята - вот вопрос по Zend Framework или лучше по MVC в целом:

Сейчас я долго спрашиваю себя, стоит ли пихать бизнес-объекты (пользователя, команду и т. Д.) В мои представления или лучше было бы просто отправить контейнеры данных дампа, такие как массивы в представление для рендеринга.

При отображении бизнес-объектов в моем представлении у меня возникает более тесная связь между представлениями и моделью моего домена, однако представление может легко выполнять такие вещи, как foreach ($ this-> team-> getUsers () как $ user) { ...} что лично мне очень удобно.

Предоставление данных модели предметной области в немых массивах для меня выглядит более надежным и гибким, но с затратами на это представление не может работать с реальными объектами и, следовательно, не может получить доступ к связанным данным, используя метод объекта.

Как вы, ребята, справляетесь с этим?

Большое спасибо, Michael

Answer 1

Лучше, чтобы ваш View обращался к объекту модели предметной области объектно-ориентированным способом, а не с помощью контроллера для преобразования данных модели в простые скаляры и массивы.

Это помогает удержать контроллер от чрезмерного увеличения веса. См. Шаблон Анемичная модель домена . Контроллеру нужно только знать, какую модель нужно создать, передать входные данные запроса в эту модель, а затем внедрить модель в скрипт View и выполнить рендеринг. Помните, что Модель предметной области не является классом доступа к данным .

Вы также можете написать View Helpers , чтобы инкапсулировать общий рендеринг объекта модели домена, чтобы вы могли повторно использовать его в нескольких скриптах View.

Ваше представление должно обращаться к доменной модели только для чтения. Скрипты представления не должны пытаться вносить изменения в модель предметной области.

Вы также можете спроектировать свою модель домена для реализации ArrayObject или других типов SPL, если это необходимо для упрощения использования ОО в сценарии View.

---

Это правда, большая движущая мотивация дизайна MVC и OO в целом - это развязка . Мы хотим, чтобы каждый слой оставался неизменным, так как другие слои изменяются. Только через их общедоступные API слои взаимодействуют.

ViewModel является одним из решений для абстрагирования модели, так что представление не нужно менять. Я обычно использую модель домена, которая абстрагирует детали проектирования таблиц и т. Д. И предоставляет API, который больше ориентирован на бизнес, а не на доступ к данным. Поэтому, если ваши базовые таблицы изменятся, View не должен знать об этом.

Я ожидаю, что если в доменной модели произойдут изменения, например, ей потребуется предоставить атрибут нового типа, то вполне вероятно, что ваше представление все равно меняется, чтобы показать этот новый атрибут в пользовательском интерфейсе.

Какой метод вы выберете для отделения одного слоя от других, зависит от того, какие типы изменений вы ожидаете чаще всего, и будут ли эти изменения действительно независимыми изменениями или в любом случае потребуют изменения нескольких слоев.

Answer 2

«Стандартный» подход будет состоять в том, чтобы полностью подготовить модель в контроллере (например, получить все команды, включая пользователей) и затем отправить ее в представление для презентации, но вы не связаны этим. Структуры данных могут быть такими, как вы хотите: Array, ArrayObject или пользовательские классы - все, что вы считаете подходящим.

Answer 3

Я сделаю все мои представления в контроллере, как показано ниже

1. модель только выходной набор данных / объекты (в нем должно быть больше всего кода)
2. контроллер назначить просмотр и добавить необходимый HTML и использовать модели
3. view содержит только заполнитель и другие материалы для презентации и, возможно, ajax call

Таким образом, моя команда может работать над каждой частью, не прерывая друг друга, это также добавляет некоторую информационную безопасность проекту, т. Е. Никто не может извлечь весь рабочий код, который они сообщают, только с помощью переменных / спецификации объекта.

Answer 4

Я не использую Zend Framework, так что это в ответ на общий MVC Посмотрите на шаблон ViewModel.

http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx

Я прихожу с точки зрения .Net MVC, но я верю, что концепции будут одинаковыми.