С идеологией MVC (model) в ZF1?

Question

[Виталий Юшкевич]

Всем доброго времени, уважаемые хабравчане.



Начал осваивать Zend Framework. Система грандиозная со своими плюсами, минусами, прелестями и сложностями. Особенно когда не совсем понимаешь best practice.



Понимаю, что запутался совсем в конец, поэтому обращаюсь к вам за помощью / подсказкой / советом, коим буду безмерно благодарен.



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



С контроллером / вью вопросов не возникло. А вот с моделью, с каждой прочитанной статьей, я понимаю, я все больше теряюсь.



Попробую сформулировать основные вопросы.

Сколько файлов под модели надо создавать?

Видел разные виды реализации наследования — от _Table, _Table_Abstract, _Row, _Rowset и тд. Когда лучше от чего наследоваться?

В идеологии ZF встречал еще использование Mapper у моделей. Как следует разделять данные? Какая часть должна работать с БД (надо ли разделять на Unit / Collection и если да, то как лучше / правильнее), а какая оперировать с различными данными. Например, различные fetch.

Есть helper, которые используют не только в качестве помощников для вью, но и для данных. Верно ли это?

Есть сервисы, которые пока полностью не освоил. С учетом вышеперечисленных вопросов про модели, что сюда лучше отдавать?



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



Если вопросы покажутся глупыми, просьба не минусовать, а помочь. Я же действительно хочу стать лучше :)

Comments

[Виталий Юшкевич]

Нашел очень достойную ссылку (http://www.slideshare.net/weierophinney/playdoh-modelling-your-objects-1766001), но если найдутся люди, готовые на пальцах своем опыте рассказать, буду очень признателен.

Answer 1

[anitspam]

Чуть-чуть личного опыта. Зенд — это мегауниверсальный фреймворк. А значит мегабольшой и мегасложный. И такое ощущение, что создавался архитекторами для архитекторов.

Поэтому, изучая его, вы не найдёте «единственных» (рекомендованных) рецептов как сделать ту или иную концептуальную вещь.
Поэтому у ваших моделей будет несколько «лишних» файлов (те самые _Table, _Row, _Rowset, плюс бывают _Gateway, _Factory, ...)
Поэтому слишком много времени будет уходить на обдумывание, как же назвать/сделать/куда поместить «простые» вещи.
Поэтому вы не сможете найти пару десятков открытых проектов, чтобы посмотреть, как же сообщество решило делать какую-нибудь штуку (эта штука будет сделана по-разному в найденных проектах).
Поэтому в багтрекере вы будете видеть тикеты, открытые по нескольку лет с риторическими вопросами «Есть какой-нибудь прогресс по этой проблеме?».

Поэтому на первых порах, пока ещё не освоили фреймворк, сделайте как можно проще, без усложнений. Если вам надо делать запросы к базе, пусть пока это будет вот так

$db = Zend_Db_Table_Abstract::getDefaultAdapter();
$query = "SELECT ...";
$db_result = $db->fetchAll($query);

потом может вам понравится вот так

$o_select = $o_db->select()
                ->from("...", $a_columns)
                ->where('... = ?', ...)
                ->order('... ASC');
$a_result = $o_db->fetchAll($o_select);

потом так

public function fetchAllBy...($...)
    {
        ...
        return new ..._Model_...Set(...);
    }

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

Comments

[Виталий Юшкевич]

Спасибо за совет :)
Советы действующие, примерно в том направлении двигался, но хотелось более плотно сесть за «правильно». Хочу сегодня сесть за вариант, который описывается в архитектуре.
Тут вопрос скорее не в том, где писать запросы в базу, а как это красивее разнести :) Именно, как вы и сказали — архитектура :)
Есть опыт работы на других ЯП, где все выглядит мега секси, хочется эстетику сохранить и приучать себя сразу к приближениям левел-апа.

Answer 2

[Kuzma]

попробуйте посмотреть на github.com/codeinchaos/restful-zend-framework. не обязательно его использовать — достаточно посмотреть как там сделано.

Блог автора этого проекта:
www.codeinchaos.com/post/3107629294/restful-services-with-zend-framework-part-1
www.codeinchaos.com/post/3645298058/restful-services-with-zend-framework-part-2

Comments

[Виталий Юшкевич]

Спасибо за совет. Видел все эти решения, включая github.com/codeinchaos/restful-zend-framework-example
Но это совсем не то. Тут подробно и очень хорошо описана работа контроллеров и ньюансы работы в режиме REST. А с этим как раз таки вопросов / проблем и не возникло. У меня основной вопрос — именно в организации моделей.

[Kuzma]

Писал-писал я вам ответ. В итоге целый пост в моем блоге родился ))
blog.nkuznetsov.me/2013/01/working-with-models-in-zendframework-1.html

[Виталий Юшкевич]

Спасибо! Это совсем то, чего хотелось.

В продолжении вопросов — а как в данном формате лучше переключать контекст, например захочется подключить работу с кэшем, или базу поменять на другую, например подключив Mongo?
И второй вопрос — есть смысл зафиксировать названия полей таблицы, на случай изменения их, чтобы волшебные геттеры / сеттеры не поломались, а использовались какие-то константы?

[Kuzma]

В продолжении вопросов — а как в данном формате лучше переключать контекст, например захочется подключить работу с кэшем, или базу поменять на другую, например подключив Mongo?

кэш запросов в БД разумно встроить в model/DbTable/Books.php.
а базу переключить в configs/application.ini можно (см. resources.db.adapter)

или под «контекстом» вы имеете в виду что переключение кэша и базы «на лету» должно быть?

И второй вопрос — есть смысл зафиксировать названия полей таблицы, на случай изменения их, чтобы волшебные геттеры / сеттеры не поломались, а использовались какие-то константы?

не уверен что понял вопрос. если вы имеете в виду что нужно что-то вроде этого:

    define('BOOK_ID','book_id');
    define('BOOK_NAME','book_name');
    define('BOOK_TITLE','book_title');
    ....
    $result = $this->fetchAll(
            $this->select()->from($this->_name,array(
                BOOK_ID,
                BOOK_NAME,
                BOOK_TITLE
            ))
        );

то нет. они все-равно поломаются, если в базе что-то случится ))

[Виталий Юшкевич]

По первому — www.slideshare.net/weierophinney/playdoh-modelling-your-objects-1766001 в районе 35-36 слайдов пример на тему подключения кэша за счет переключения маппера

Answer 3

[mbt]

Я создаю 2 файла: application/models/DbTable/Items.php

class Application_Model_DbTable_Items extends Zend_Db_Table_Abstract
{
    protected $_rowClass = 'Application_Model_Item';
    protected $_name = 'items'; //Table name
}

application/models/Item.php

class Application_Model_Item extends Zend_Db_Table_Row_Abstract
{
    public function getName(){
        return $this->title; //database table column
    }
}

Потом в контроллер:

$itemsTable = new Application_Model_DbTable_Items();
$items = $itemsTable->fetchAll();
foreach($items as $item){
    echo $item->getName() . '-';
}

Преимущество такого метода в модели можно писать дополнительные функции. DbTable возвращаеть объект Application_Model_Item