Data mapper и компонента view

Nicki

Новичок
Data mapper и компонента view

У меня вот такой вопрос... Наверное будете смеятся над его простотой, вроде как проблема из пальца высосана. Но хочется убедится что я правильно делаю.

Я не совсем понимаю как правильно реализовать работу контроллера при использовании паттерна Data Mapper в схеме MVC. Дело в том, что дата маппер у меня статический класс, а не объект:

PHP:
class Article_Mapper  
{
    static function insert(Article $Article) {}
    static function update(Article $Article) {}
    static function getById(Int $id) {}
    static function getAllArticles() {}
}
Я насколько понимаю, компонент view, данные для представления должна получать только от модели (так ведь?). Т.е у нас получается что контроллер создает модель, выбирает и создает представление, затем модель передается представлению и соответственно к объекту представления обращаемся для визуализации данных модели.

PHP:
Article_Mapper::setDao($Dao);
$Article = Article_Mapper::getArticleById($id);

$ArticleView = new Article_ShowArticle;
$ArticleView->setArticle($Article);
$ArticleView->display();
А как быть если нужно вывести список статей? Я обращаюсь к Article_Mapper::getAllArticles(); получаю массив объектов Articles и его передаю в представление?
 

zerkms

TDD infected
Команда форума
в представлении получить массив и работать с ним?
 

Nicki

Новичок
т.е. надо в представлении вызывать тогда Article_Mapper::getAllArticles(); а не в контроллере?
 

Nicki

Новичок
понятно. а ничего что для вывода одной статьи, получаем ее модель в контроллере и передаем ее уже в представление, а для вывода списка контроллер только создает представление и вызывает метод визуализации? Это ведь получается два разных подхода.


PHP:
// вывод одной статьи
$Article = Article_Mapper::getArticleById($id);
$ArticleView = new Article_ShowArticle;
$ArticleView->setArticle($Article);
$ArticleView->display();


// вывод списка статей
class Article_ShowListArticles
{
    function __construct()
    {
         $this->Articles = Article_Mapper::getAllArticles();
    }   
...
}

$ArticleView = new Article_ShowListArticles();
$ArticleView->display();
А если мне нужно будет обратится не к Article_Mapper::getAllArticles(); а к Article_Mapper::getOnlyNewArticles();, то придется реализовывать перегрузку метода конструктора? Может быть тогда правильнее и при выводе одной статьи получать модель не в контроллере а в представлении?
 

rotoZOOM

ACM maniac
PHP:
$Article = Article_Mapper::getArticleById($id);
Это у тебя в контроллере написано как я понимаю. Но функции контроллера расссказать модели о произошедших изменениях, а дальше по логике модель сообщает представлению(ям) о том, что произошли изменения и уже представления запрашивают новые данные у модели сами. Судя по этой логике, контроллер вообще не должен запрашивать данных у модели для представления. Оно (представление) должно брать их само у модели. Поэтому для меня ИМХО второй вариант более предпочтительный.
 

Nicki

Новичок
Да, это у меня написано в контроллере.
Но функции контроллера расссказать модели о произошедших изменениях, а дальше по логике модель сообщает представлению(ям) о том, что произошли изменения и уже представления запрашивают новые данные у модели сами.
А у фаулера написано что:

Представление отображает содерживое модели....
Функции представления заключаются только в отображении информации на экране. Все изменения информации обрабатываются третьим участником системы - контроллером. Контроллер получает входные данные от пользователя, выполняет операции над моделью, и указывает представлению на необходимость соответствующего обновления.
...
Отделение представления от модели - это один из фундаментальных принципов проектирования программного обеспечения.
Может быть все таки контроллер оповещает представление об обновлении, а не модель? Модель ведь вообще не должна ничего знать об представлении. В тоже время представление должно запрашивать данные у модели... значит, все таки обращаться к мапперу нужно из представления. Маппер это фактически часть модели или нет?
 

Nicki

Новичок
http://ru.wikipedia.org/wiki/Mvc
Поведение (Controller). Интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции.
Модель не должна знать о контроллере и о представлении, а значит и не может информировать представление о изменении состояния модели. Этим занимается контроллер. И на диаграмме видно, что модель не знает о представлении, но возвращает ей свои данные. А вот контроллер знает судя по всему знает и о модели и о представлении.

Может кто нибудь приведет свои куски кода взаимодействия дата маппера и компоненты представления?

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

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

john.brown

просто кулибин
Имхо, представление ничего не должно знать о модели (как и о контроллере). Вся работа с моделью происходит в контроллере. Представление работает только с подготовленными простыми типами данных, типа строки, массивы...

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

Gas

может по одной?
Имхо, представление ничего не должно знать о модели (как и о контроллере). Вся работа с моделью происходит в контроллере. Представление работает только с подготовленными простыми типами данных
+1, у меня такой-же подход.
ну разве что к простому типу можно отнести коллекцию объектов.
 

Nicki

Новичок
Как изменение количества статей связано с mvc?
Не знаю, просто мысль... Просто фактически $Article это модель статьи - если что то изменится в статье, то можно просто запросить новые данные у модели, прямо из представления. А массив статей, это не модель, т.к. нет такого типа данных в модели как список-статей. И если этот список изменился, его нужно заново запросить у маппера, а значит метод маппера должен вызываться в представлении.
Короче я запутался совсем.

-~{}~ 11.08.08 16:44:

Автор оригинала: Gas
ну разве что к простому типу можно отнести коллекцию объектов.
это уже интересно...
 

Gas

может по одной?
В какой момент может измениться список статей или сама статья? В контроллере получил все нужные данные, отдал их представлению, если за 0,0....1сек (пока представление показывает данные) что-то и изменится, то и фиг с ним.

это уже интересно...
а что тут интересного, всего лишь массив объектов "Статья", например.
 

Nicki

Новичок
хм... точно... а то наверное слишком глубоко копать стал.
 

rotoZOOM

ACM maniac
Модель не должна знать о контроллере и о представлении, а значит и не может информировать представление о изменении состояния модели.
Модель и не будет знать ни о контроллере ни о представлении, она может являться observer'ом. А вот представление как раз вполне может знать о модели (например она передана в конструкторе представления контроллером), и подписываться у нее на изменение состояния. Есть несколько способов формирования данных для представления, одним из них как раз пользуется Gas, то есть контроллер формирует все данные для представления. А можно реализовать и получение необходимых данных самим представлением (если оно знает модель естественно).
Есть свои плюсы и минусы и у того и у другого способа. Выбирать тебе.
 

е1

Новичок
" Модель, как уже было отмечено выше, инкапсулирует ядро данных и основной функционал по их обработке. Также компонент Модель не зависит от процесса ввода или вывода данных. "

Наверное, изменения надо вносить через Контроллер, всеже.
 

Ilya Bous

Новичок
А хотите еще маленечко проблем с DataMapper? Цитата: "Since it's a form of Mapper (473), Data Mapper itself is even unknown to the domain layer." вот отсюда: http://martinfowler.com/eaaCatalog/dataMapper.html

Так вот, поскольку модель - это собственно domain layer который ничего не знает о маппере, то ежели вы вызываете статический класс инкапсулирующий логику работы с БД в модели, то получаете просто напросто разновидность активной записи (объекты domain layer знают о маппере, а маппер (само собой разумеется) знает об объектах которые он создает и сохраняет). Вот такая вот фигня =)
 
Сверху