Куда относится логика обработки форм в веб-приложении MVC?

Question

В веб-приложении, использующем шаблон проектирования Model-View-Controller, логика, относящаяся к обработке отправки форм, кажется, находится где-то между уровнем модели и уровнем контроллера. Это особенно верно в случае сложной формы (т. Е. Когда обработка формы выходит далеко за рамки простых операций CRUD).

Какой лучший способ осмыслить это? Являются ли формы просто своего рода связующим звеном между моделями и контроллерами? Или логика форм принадлежит прямо в лагере М или С?

РЕДАКТИРОВАТЬ: я понимаю основной поток информации в приложении MVC (см. Краткий обзор ответа chills42). У меня вопрос, к чему относится логика обработки формы - в контроллере, в модели или где-то еще?

Answer 1

Я бы сказал, что это, вероятно, следует рассматривать как 2 отдельных действия ...

1. отправка формы (V -> C)
2. обработка представления (C -> M)

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

• Форма отображения (C -> V)
• Отправлено пользователем (V -> C)
• Содержание процесса (C -> M)
• Обработка завершена (M -> C)
• Отображение результатов (C -> V)

Answer 2

Хотя поначалу идея использования V -> C, C -> M, M -> C выглядит хорошо, любое изменение в форме требует вмешательства в представление «контроллер + модель +». Этого следует избегать, чтобы сохранить логику приложения простой. Вот очень простое расширение фреймворка, которое действительно облегчает обработку веб-форм, делегируя логику обработки форм отдельному классу и сохраняя архитектуру MVC для обработки логики приложения.

Для каждой формы, которую вам нужно обработать, создайте класс, производный от общего класса "webform", или класса модели codeigniter. Добавьте методы, такие как validate (), process (), display () в этот класс.

В контроллере код становится таким:

class User_controller
{

    function login()
    {
        $form = new LoginForm(); // this is the class you would create
        if ($form->validate())
        {
            $data = $this->user_model->getUserData( $form->userid );
            // form processing complete, use the main "user" model to fetch userdata for display,
            // or redirect user to another page, update your session, anything you like
        } else {
            $form->display();
        }
    }
}

Метод display в классе формы загружает свое собственное представление и заполняет данные обратной отправки по желанию. Используя вышеизложенное, есть несколько преимуществ:

• Вам не нужно менять основной контроллер, если необходимо изменить отображение или обработку формы.

• Вам также не нужно менять свою пользовательскую модель

• Контроллер остается чистым и обрабатывает логику главной страницы

• Пользовательская модель остается очищенной и взаимодействует только с базой данных

Фреймворк сам может быть обновлен, так что веб-формы могут быть загружены с помощью

$ this-> load-> форма ( "Вход"); ......

Однако это только предложение, которое полезно для команды codeigniter.

Answer 3

Согласитесь с chills42, но добавьте в модель как можно больше деталей.
Когда пользователь отправляет (V-> C), он будет передан какому-то контроллеру, и я утверждаю, что лучше всего, если контроллер просто действует как диспетчер, чтобы решить, что будет дальше, возможно, основываясь на некоторой простой точке данных. Пусть модель имеет метод (обычно не строго ORM или основанный на активной записи), который обрабатывает необработанные данные и сохраняет их в БД, если необходимо, затем просто возвращает состояние или выдает ошибку.

Answer 4

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