Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Теоретический вопрос о моделях в MVC фреймворках и способе возврата вычисляемых  (Прочитано 8167 раз)
0 Пользователей и 3 Гостей смотрят эту тему.
LukiDuki1980
Новенький

ru
Offline Offline

« : 19-04-2015 14:03 » 

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

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

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 19-04-2015 14:52 » 

При чем тут таблицы?

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

MVC (либо MVP) не должны иметь к этому никакого отношения.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
LukiDuki1980
Новенький

ru
Offline Offline

« Ответ #2 : 19-04-2015 15:12 » 

При чем тут таблицы?

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

MVC (либо MVP) не должны иметь к этому никакого отношения.

модель возвращает сущность (entity) объект представляющий записи из бд (например класс Post), но что если нужно вернуть больше чем просто записи из бд?
Записан
Qulac
Постоялец

ru
Offline Offline

« Ответ #3 : 19-04-2015 16:41 » 

LukiDuki1980, это от ситуации зависит, конкретика нужна что бы сказать.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 19-04-2015 17:19 » 

модель возвращает сущность (entity) объект представляющий записи из бд (например класс Post), но что если нужно вернуть больше чем просто записи из бд?

Как-то идея оказалась вывернутой наизнанку... Не модель должна представлять записи из БД, а БД должна использоваться как (вспомогательное) средство хранения данных для модели, если это нужно.

Основная идея паттерна:
M (Model) - модель предметной области, для которой разработано приложение.
V (View) - представление, т.е. визуальный интерфейс для вывода данных модели и организации взаимодействия пользователя с программой.
C (Controller) либо P (Presenter) - координатор между моделью и представлением.

Все, никаких таблиц, баз данных и прочих посторонних предметов. Если модель использует базу данных для своих нужд - ее внутреннее дело, хотя с таким же успехом может использоваться сохранение данных в XML либо хранилище NoSQL. Никакого отношения к паттерну MVC/MVP это не имеет.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 19-04-2015 17:21 » 

Все зависит от реализации моделей в фреймворке или самой MVC системы

Например, самое простое - объединение
Код:
class Model {

public function getData(){
  $query = "Query";
  $result = $store->get($query);
  $calculate = $this->calculate($result);
  return merge($result,$calculate);
}
protected function calculate($data){
  ....
  return $calculateData;
}


}
Более сложное решение (наличие системы событий)
Код:
class Model {

public function getData(){
  $eventBefore();

  $query = "Query";
  $result = $store->get($query);
  $calculate = $this->calculate($result);
 
  $eventAfter();
}
protected function calculate($data){
  ....
  return $calculateData;
}


}


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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
LukiDuki1980
Новенький

ru
Offline Offline

« Ответ #6 : 20-04-2015 12:19 » 

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


1) Просто вернуть массив,
где одно значение это объект Post (результат из БД), а второй вычисленные данные (ну то же, что в вашем примере merge($result,$calculate);)

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


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

class Model {

public function getData(){
  $query = "Query";
  $result = $store->get($query);
  $result->setSmthParam1($calculateSmth1());
  $result->setSmthParam2($calculateSmth2());
  return $result;
}
...
}

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

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


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

public function getData(){
  $query = "Query";
  $post = $store->get($query);
  $result = [
    'post' => $post,
    'smthParams' => $this->calculateSmth()
  ];
 
  return $result;
}
...
}

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

public function getData(){
  $query = "Query";
  $post = $store->get($query);
  $result = new OverPost()
  $result->setPostData($post);
  $result->setSmthParam($this->calculateSmth())
 
  return $result;
}
...
}


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

Код:
class Model {

public function getData(){
  $query = "Query";
  $post = $store->get($query);
  $post->setSmthParam($this->calculateSmth());
  return $post;
}
...
}

В общем какой вариант будет правильней, с точки зрения дизайна кода, с точки зрения MVC и с точки зрения нынешнего стиля фреймворков?
« Последнее редактирование: 20-04-2015 13:38 от LukiDuki1980 » Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 21-04-2015 07:51 » 

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

Любой вариант правильный, все зависит от реализации основных классов FW

Да кто его знает нынешний стиль

За всеми не уследишь Улыбаюсь

MVC - это всего лишь, малая часть OOP


например, посмотрите jquery

практически все методы возвращают element,
поэтому возможны длинные конструкции
$(elem).parent().next().delay() и т.д
Конечно есть методы возвращающие значения.
И посмотрите в плагины...
Т.е. для создавая плагин, или класс он добавляет функционал, а все данные хранятся в экземпляре, или объекте
 
 
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
RXL
Технический
Администратор

Offline Offline
Пол: Мужской

WWW
« Ответ #8 : 21-04-2015 09:40 » 

Я бы гуглил не по "MVC", а по "ORM".
Модель - это просто класс. Ничего не мешает реализовать в нем дополнительные сервисные методы.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines