Zend_Db – объекты модели, связи и сложные условия

[Voenniy]

Спасибо за статью.
Про ACL было бы очень интересно — выложите пожалуйста.

[filipchuk]

Про MVC читали? В контроллере не должно быть бизнес-логики, и запросов в БД включительно

[VSV]

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

[filipchuk]

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

[VSV]

Согласен.

[dohtar]

Вы движетесь к magento, поздравляю!
Точнее к Varien, на котором написана magento.

[d3z]

Этот контроллер тонкий? Тонкий контроллер выглядит так (впрочем и этот немного жирноват):

class Users_IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->user = new Users_Model_User();
    }
}

А о связях между таблицами советую почитать в руководстве. А затем вынести все эти связи как минимум в маппер.

[VSV]

Приведите, пожалуйста, пример использования Zend'овских связей и мапперов. И опишите, насколько это удобно, если не сложно.

[VSV]

Тонкий контроллер покажите с переданными ему параметрами

[d3z]

Хорошо. Готовы немного подождать?

[VSV]

Да, спасибо. Вообще конструктивная критика очень полезна.

[d3z]

Вот пример контроллера, который позволяет просмотр и редактирование пользовательского профиля.
Используется активная инверсия зависимостей для получении параметров.

class Users_ProfileController extends Zend_Controller_Action
{
    protected $user;

    public function init()
    {
        $this->user = new Users_Model_User();
        if (!$this->user->find( $this->_getParam('id') )) {
            return $this->_forward( /* 404 Not found */ );
        }
    }

    public function indexAction()
    {
        $this->view->user = $this->user;
    }

    public function editAction()
    {
        $form = new Users_Form_User();
        $this->view->form = $form;

        $form->populate( $this->user->getOptions() );

        if (!$this->getRequest()->isPost()) {
            return;
        }

        if (!$form->isValid( $this->getRequest()->getPost() )) {
            return;
        }

        $this->user->setOptions( $form->getValues() );
        $this->user->save();
        
        $this->_forward('index');
    }
}

[Gibbzy]

Что то тут не так.
Объясните мне пожалуйста чем это удобнее.
Читая тот код который вы представили в контроллере, мне показалось что это не чуть не проще и не меньше, чем обыкновенные джойны, пусть даже если возвращает это всё доменные объекты.
Как мне показалось вы представили что то типа надстройки над Zend_Db_Select, которая умеет выбирать данные.

А как же независимость объектов от хранилища данных.
А ещё если так активно используете Zend_Db_Table_Row метаданные таблицы лучше кэшировать(хотя я мог просмотреть может оно там где то и кэшируется.)

ИМХО: сопеть и писать мапперы, тихо ждя пока выйдет zf 2.0 и Doctrine 2.0 и будет всем счастье.

[d3z]

Вы не подумайте что я издеваюсь, но почему после выхода zf 2.0 пропадёт необходимость в мапперах? Я просто не в курсе, там что-то принципиально новое обещается?

[Gibbzy]

Интеграцию doctrine и ZF вроде как обещают. Надеюсь что будет как в ror — тоесть быстрая генерация моделей с последующим их допилом напильником

[Gibbzy]

framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
вот официальный roadmap.
Но про генерацию моделей, я сплю и вижу и ножками во сне дрыгаю. Во всяком случае это должно когда то случится.

[d3z]

Благодарю! Прочту на досуге.

[d3z]

Doctrine — тот же маппер, вид сбоку. Впрочем ладно, чёрт с ними, с тонкостями реализации. Наша с Вами основная задача — убедить автора статьи в необходимости такой абстракции.

[Gibbzy]

Мапперы написанные на коленке кем то там не сравнятся с doctrine, это ORM, и там всего побольше будет чем просто в маппере, да и разрабатывает её не один человек.

[d3z]

Я согласен, но это всё же частный случай маппера. Поэтому — вид сбоку, со стороны реляционных баз данных.
К примеру, в текущем проекте мне потребовались мапперы для хранения моделей в Active Directory.

[VSV]

Сильно сказано!
К сожалению, ваш контроллер отличается от моего… примерно на 60 секунд рефакторинга. Я без споров за такое время вынесу выборку данных из контроллера. Это был неудачный, как Вы показали, контроллер, остальные даже править не придется — клоны вашего :).

Я же хотел акцентировать внимание (заглавие топика) на построитель SQL, запрятанные в нем JOIN'ы и WHERE.
Уверен, что существуют гораздо лучшие решения, изящные и концептуально-правильные, но пока мне говорят о них только в теории или в теории будущего.
Показав свою реализацию, я хотел спровоцировать опытных разработчиков похвастаться их наработками.

[VSV]

Добавил к топику пропущенный случайно view template.
Вобщем-то акцент стоит на том как получать данные из БД, и как ими оперировать.

[VSV]

Хотелось бы услышать на какие «грабли» я могу наступить с таким подходом к модели данных.
И также ваши практические примеры решения подобных проблем.