MVC дизайн в кодеигнитора PHP

Question

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

Answer 1

Прежде всего, вы не можете на самом деле реализовать классический MVC в php. Лучшее, что вы можете сделать, это Model2 MVC.

• Модель - отвечает за всю бизнес-логику. Не имеет понятия о , где данные хранятся или фактически поступают. Хранение и извлечение является обязанностью DataMappers или DAO. Сама модель не должна никогда содержать SQL. Когда-либо.
• Контроллер - привязывает модель (и) к виду и изменяет состояние обоих. не извлекает информацию из моделей для отправки ее на просмотр.
• Просмотр - отвечает за всю логику представления. Извлекает информацию из моделей и привязывает ее к соответствующим шаблонам. Просмотр самого себя не является шаблоном .

Вы можете иметь 1:1 связь между представлениями контроллера или many:many. это зависит от того, как вы реализуете само представление.

Например, вашему представлению может потребоваться отдельный объект, который обрабатывает рендеринг. И предоставляя различные типы объектов (это где полиморфизм имеет значение), вы можете сделать так, чтобы ваше представление отображало xml, html или json.

Или вы можете сделать то же самое, изменив шаблоны. Класс ListView может отображать список статей, а также список пользователей, если базовая логика представления не меняется и вы предоставляете только разные шаблоны для каждого.

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

Answer 2

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

Что касается вашего примера "голосования", это может зависеть от того, как будет использоваться голосование на вашем сайте. Будут ли голоса появляться на страницах разных типов? Если так, какой-то компонент является хорошим подходом; представление компонента голосования может затем использоваться для отображения его данных на разных страницах, при этом контроллер компонента голосования принимает результаты голосования, а затем, возможно, перенаправляет его куда-то еще (или принимает голоса по запросу Ajax).

Очень часто вы обнаруживаете, что модели (и контроллеры) более или менее соответствуют 1: 1 таблицам в базе данных. Поэтому, если у меня есть таблица users, у меня может быть соответствующая модель User и контроллер UserController.

Помните, для чего предназначен контроллер: ответьте на запрос, определите, какие модели необходимо загрузить, затем попросите их сохранить, манипулировать и вернуть данные, которые затем передаются в представление для отображения. Хорошо иметь контроллеры, которые не отображаются напрямую на модели. У вас может быть контроллер с именем DebugController, который отвечает на запросы к http://examples.com/debug/ и не отображается непосредственно на модель и таблицу Debug, но собирает информацию о системе и различных моделях (конечно, есть аргумент что все эти вещи должны быть объединены в модель Debug, которая, в свою очередь, загружает другие модели и собирает данные, которые запрашивает контроллер).

Что касается представлений, у вас обычно будет несколько представлений для данного контроллера; часто один просмотр за действие . Так что UserController::indexAction() имеет views/user/index.php, UserController::editAction() имеет views/user/edit.php и т. Д.

Answer 3

Подход может быть гибким, это правда.

Модели - Опишите уровень, который напрямую связывается с базой данных, всеми запросами SQL.Вы можете иметь модель для каждой таблицы в БД, которая будет обрабатывать все действия, связанные с этой таблицей (выбрать, вставить, обновить, удалить).Вы можете иметь модель для каждого «логического объекта», модуль в вашем приложении, который будет обрабатывать действия для этого объекта.Как и в вашем примере «Голосование», где вы можете определить логику этого модуля.(Проверьте, проголосовал ли пользователь уже, getVoteCount ...)

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

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