Вопрос у меня не конкретно к какому-то фреймворку, а в целом, так скажем по теории.

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

Раньше, скажем в PHP, это решалось просто, к возвращенному массиву просто добавляли новые значения и возвращали весь список, а как решать эту проблему на уровне текущих абстракций фреймворков? В класс (отражающий таблицу) добавлять дополнительные поля? Или же создать отдельный класс, который включает как вычисляемые данные, так и объект с БД?

Смотря что вычисляется и относится ли это к самой модели.

Самыми современными средствами - магией   __call, __get и т.д. Магическими методами можно реализовать ленивую загрузку...

Если аналогии искать, то PHP - это, с точки зрения скульптора, зубило и молоток. А MVC - это высказывание Микеланджело - "Я беру камень и отсекаю всё лишнее". С точки зрения эстетики - красиво, с точки зрения практики - малоприменимо. 

Версия вопроса 2.0 (с кодом).
Условие, после обработки из БД формируется результат в виде некого объекта класса Post, в котором описаны поля таблиц (ORM иди ActiveRecord не важно).
Вопрос.
Как с точки зрения ООП дизайна поступить, то есть что вернуть контроллеру?


1) Просто вернуть массив, где одно значение это объект Post (результат из БД), а второй вычисленные данные.


2) Создать какой-то выше по уровню класс типа OverPost, которые бы включал в себя объект (результат из БД), и вычисленные данные (по сути тот же массив только в обертке ООП со всеми плюшками).



3) Заранее расширить класс Post, чтобы он содержал данные не только с таблиц БД, а так же вычисляемые данные.



В общем какой вариант будет правильней, с точки зрения дизайна кода, с точки зрения MVC и с точки зрения нынешнего стиля фреймворков?

Модель должна производить коммуникацию с ДБ. 

Оригинальная MVC модель говорит о том что изначально коммуникация идет в Контроллер, затем в модель и после в "View".
 
Но на практике MVC контроллер ведёт коммуникацию со "View". Контроллер, используя параметры POST / GET, отправляет их в Модель и Библиотеки для того чтобы вывести резултать во "View"

"The Model represents your data structures. Typically your model classes will contain functions that help you retrieve, insert, and update information in your database."
https://ellislab.com/codeigniter/user-guide...erview/mvc.html

То-есть модель используется для коммуникаций с ДБ. после того как ты получил резултать с Модели это резултать поступает в Библиотеку и делает нужную операцию и затем "View" это все показывает.


Это сообщение отредактировал(а) Spiker - 20.4.2015, 16:50

Вот только не надо путать объект доступа к данным и MVC-модель. MVC-модель может получить все данные, которые требуются для View. Если взять, для примера, карточку товара в магазине, то вместе со свойствами самого товара, объект должен  уметь выдать описание бренда (другая таблица), список "с этим товаром обычно покупают" - отдельный список товаров, список категорий товара - отдельная таблица и т.д.

пример, контроллер



Это сообщение отредактировал(а) Spiker - 20.4.2015, 18:42

Spiker, Итого, для того, чтобы view cмог отобразить "related_items", знание о наличии related_items обязано быть прописано в контролере, в модели, где они собственно и выковыриваются и во view. в 3-х местах.
А вот если использовать "магию", то можно эту сущьность упоминать только в 2-х. Во view будет написано что-то вроде


В магии класса $data определить все необходимые поля, которые нужны view.

Это лучше?

И что тогда станет с контролером? Редуцируется до 1-2 строчек? 

Из MVC можно использовать только дисциплину - все классы обязаны определиться для себя - к какому "классу" они относятся. Если используется JS или HTML - то однозначно view. Если лезем в базу - однозначно - модель. Если лезем в$_GET/$_POST, вероятнее всего, контроллер. А если все сразу -это не MVC   


Можно пойти чуть дальше... В простейшем случае, главный контроллер приложения можно свести к конфигурации. Тоесть, он, фактически, кроме случая обработки форм, становится не особенно и велик - сводится к одной функции довольно универсального вида. Функция обязана по виду GET или расположению звезд, определить, какой view необходимо вывести. Данные формировать, фактически, нет необходимости.
MVC-модель тоже можно "редуцировать" до одного единственного объекта. СамойГлавнойМодели. Уже она будет выдавать нам все необходимые данные для именно этого view. Обычно, такое уже есть - объект $APPLICATION, или  Yii::app() и т.д.
Например, для случая вывода карточки товара, контроллер обязан выявить и припрятать в собственных параметрах ID необходимого товара. View первым делом запросит у СамогоГлавногоМодуля - "дай мне текущий товар". А дальше уже примерно ясно.
В итоге получается MVC из 1-й функции контроллера, одного класса MVC-модель и кучи view. Не особенно по классике, но чем не MVC?   


Это сообщение отредактировал(а) ksnk - 21.4.2015, 12:17

я создал быстрый пример ящика с сообщениями для обсуждения, я не использовал магические методы, в контроллере есть две возможные операции: просмотр сообщений и просмотр сообщения; написано для CodeIgniter.



Это сообщение отредактировал(а) Spiker - 22.4.2015, 18:52

Присоединённый файл ( Кол-во скачиваний: 0 )
 messages_controller.zip 1,80 Kb