Должен ли я создавать классы Model и DAO для элементов страницы?

Забавный вопрос: в веб-приложении MVC для кинотеатра у меня есть классы Model, такие как Film и Showing. Кроме того, у меня есть классы DAO, такие как FilmDAO и ShowingDAO, для извлечения данных из БД...

Мой вопрос: должен ли я создавать классы для вещей, которые не являются реальными "сущностями", а просто элементами страницы? Я имею в виду такие классы, как Carousel или Sidebar, и соответствующие им DAO.

Я думаю, что это действительно странно иметь SidebarDAO, однако это также то, что извлекается из БД из контроллера для отображения на странице...


person MikO    schedule 12.06.2014    source источник
comment
прочитайте c2.com/cgi/wiki?DomainObject и перестаньте называть их моделями   -  person tereško    schedule 13.06.2014
comment
@tereško, тогда, по вашему мнению, и Film, и Sidebar являются объектами домена моего приложения, и поэтому с ними следует обращаться одинаково?   -  person MikO    schedule 13.06.2014
comment
На самом деле Sidebar будет объектом представления и использоваться представлениями. Кроме того, вы можете найти это полезным: stackoverflow.com/a/16596704/727208   -  person tereško    schedule 13.06.2014
comment
Спасибо @tereško. Я читал некоторые ваши интересные ответы... Только один вопрос: то, что вы называете Объектами представления, в значительной степени совпадает с классами ViewModel, которые использует L-Three. в его ответе ниже или определенных здесь, например: fuelphp.com/docs/general/ viewmodels.html или нет?   -  person MikO    schedule 13.06.2014
comment
ViewModel на самом деле заменяет контроллер в MVVM. Это структура, которую вы используете, когда у вас нет контроля над API модели и/или представлением (обычно это случай, когда вы выполняете интеграцию со сторонней системой). Модели представления FuelPHP — это еще одно искажение простых php-шаблонов ... вам действительно не стоит изучать архитектуру приложения у Fuel.   -  person tereško    schedule 13.06.2014


Ответы (1)


Модели, на которые вы ссылаетесь, такие как Film, представляют данные, используемые представлением. Это М в MVC. На самом деле, мне нравится рассматривать их как модели представлений, поскольку вы, вероятно, захотите, чтобы они были оптимизированы для определенного представления. Таким образом, у каждого представления будет своя конкретная модель представления; в котором вы могли бы повторно использовать определенные общие модели, конечно.

Это не имеет ничего общего с объектами данных, которые являются частью бэкэнда, а не внешнего интерфейса. Объекты данных просто представляют объекты в том виде, в каком они хранятся в базе данных, и они, вероятно, полностью отличаются от моделей представления.

В вашем случае Carousel, вероятно, является просто элементом управления, который вы используете на одной или нескольких страницах. Это означает, что вы можете создать модель представления карусели, содержащую всю информацию для карусели, чтобы все отображалось правильно. Модель представления карусели может быть свойством модели представления страницы, которая передается на страницу. Контроллер отвечает за получение данных из базы данных в виде объектов данных, сопоставление этих объектов данных с моделью просмотра страницы и моделью просмотра карусели и передачу их в представление.

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

person L-Four    schedule 13.06.2014
comment
Спасибо, концепция классов ViewModel интересна, я никогда раньше о ней не слышал... - person MikO; 13.06.2014