Где Zend_Form вписывается в парадигму Model View Controller - PullRequest
Новая
       15

Где Zend_Form вписывается в парадигму Model View Controller

8 голосов
/ 21 октября 2010

Zend Framework 1002 * в основном предназначен для использования в MVC.Один из самых полезных компонентов: Zend_Form .

У меня возникли проблемы с поиском места Zend_Form.Является ли это частью представления, модели или контроллера и какие обязанности я должен ему дать.

Дело в том, что Zend_Form выполняет две функции: украшает и отображает форму и проверяет ее.Первая - это задача реального просмотра, вторая - задача реальной модели.

В настоящее время наиболее распространенным применением, по-видимому, является взаимодействие форм только с контроллером, что эффективно помещает обе задачи (рендеринг и проверка) вview / controller.

Другая опция, предоставленная Мэтью Вейером О'Финни , заключается в том, чтобы прикрепить форму к вашей модели и добавить более поздние параметры просмотра в контроллер.

Итак, я сомневаюсь.Где в шаблоне MVC я должен разместить Zend_Form и как его использовать?

Редактировать Хорошие ответы, спасибо!Я назначу награду за час или два до истечения срока ее действия, поэтому, пожалуйста, дайте ответ, если у вас есть еще мысли!

Ответы [ 3 ]

5 голосов
/ 25 октября 2010

Zend_Form можно просматривать в разных точках.Он вообще не может рассматриваться как часть одного слоя шаблона MVC.

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

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

Когда вы вызываете Zend_Form из уровня контроллера, вы можете считать, что вы вызываете один ресурс модели для выполнения проверок и действий по фильтрациии решить, является ли это действительным вводом.Например: 

public function newAction()
{
    $form = $this->getForm();

    if($this->getRequest()->isPost()) 
    {
        $formData = $this->_request->getPost();

        if($form->isValid($formData))
        {
            $Model = $this->getModel();
            $id = $Model->insert($form->getValues());
        }
    }

    $this->view->form = $form;
}

Привязка форм к модели может считаться хорошей практикой, поскольку при выполнении действий по фильтрации и проверке вы находитесь на уровне модели.Итак, как предложил Мэтью: 

class Model_DbTable_Users extends Zend_Db_Table
{
    protected $_name = 'users';  
    protected $_form;

    public function getForm()
    {
        if(!$this->_form)
            $this->_form = new Form_User();
        return $this->_form;
    }

    public function add($data)
    {
        $form = $this->getForm();
        if(!$form->isValid($data)) return false;

        if($form->getValue('id'))
        {
            $id = (int) $form->getValue('id');
            $this->update($form->getValues(), 'id =' . $id);
        }   
        else
        {
            $id = $this->insert($form->getValues());
        }
        return $id;
    }
}

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

Наконец, вы можете проанализировать свой контекст и выбрать один из этих двух подходов.

В настоящее время я выбираю привязку форм к моделям.Выглядит хорошо!И имеет для меня большой смысл.

2 голосов
/ 29 октября 2010

ИМО, Zend_Form предназначен для ношения нескольких шляп. Это, по сути, мост между видом и моделью с гигантской опорной балкой от контроллера.

Вместо назначения формы для модели рассмотрите возможность назначения модели (ей) на форму.

На уровне модели у вас может быть метод getFormInputs, который может возвращать элементы, необходимые для ввода данных. Модель не заботится о том, какая форма будет использовать ее, она просто делает ее доступной любому, кто захочет.

Теперь в вашем слое формы создайте метод setupInputs, который будет проходить через массив моделей, чтобы захватить все входные данные. Если была только одна модель, добавьте входные данные в форму. Если было более одной модели, сделайте субформы.

Ваш контроллер запустит форму и передаст значения обратно в модель (см. Метод newAction Кейна)

1 голос
/ 22 октября 2010

Zend_Form часто чувствует себя странным человеком. Я думаю, что пробег у всех разный.

В последнее время большинство моих административных интерфейсов были очень перетаскиваемыми AJAX-y, и они требуют большого количества html и javascript - реальные элементы формы редки. Поэтому я решил отказаться от многих функций Zend_Form и использовать его в качестве вспомогательного средства представления с фильтрацией. Все мои проверки выполняются на отдельном слое в модели.

Я думаю, что идея О'Финни также имеет большой смысл. Здесь он предпочитает думать о форме почти как о компоненте доменного объекта - где он может добавить бизнес-логику. Это звучит просто отлично, если вы будете осторожны, чтобы сохранить всю логику представления для формы отдельно. Как он отмечает, речь идет о том, чтобы иметь смысловой смысл. Не обязательно жесткое и быстрое правило.

...