Переход к официальным ресурсам:      Codeigniter4 / Документация / Github / Форум / CodeIgniter3
Привет! В настоящий момент я временно прекратил перевод документации по причине того, что она она содержит целый ряд неточностей, а также еще дорабатывается со стороны разработчиков. Если ты заинтересован в изучении фреймворка CodeIgniter 4, то приглашаю тебя на свой канал на YouTube (Перейти на канал), где я более подробно выкладываю занятия по данному фреймворку.


Модель, Представление, Контроллер

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

В современном мире web-разработок большинство профессиональных разработчиков уже давно остановили свой выбор на шаблоне (паттерне) проектирования MVC. Значение этой аббревиатуры формируется от трех английских слов: Model-View-Controller (Модель-Представление-Контроллер). Это очень удобный шаблон проектирования, который позволяет не только организовать весь код проекта в удобном для обслуживания виде, но еще и четко отделить бизнес-логику приложения от представления.

Если ты еще новичек и не знаком с паттерном MVC, то совсем уж простыми словами это можно объяснить примерно так: бизнес-логика - это весь php-код, который что-то проверяет, обрабатывает, осуществляет запросы к базе данных и формирует конечный результат, который необходимо показать пользователю. Представления (или их еще называют Виды) - это обычные (почти) html-страницы, задача которых, просто вывести на экран подготовленные бизнес-логикой результаты. Вся прелесть данного шаблона проектирования заключается в четком разграничении кода, когда бизнес-логика написана в одних файлах, а представления - в других. Таким образом, верстальщикам не требуется разбираться в тонкостях php-кода и запросах к базам данных, а php-разработчикам не нужно излишне акцентировать свое внимание на том, в каком виде эти данные будут показаны пользователям. При коллективной разработке проекта, каждый сконцентрирован на своем участке работы, не затрагивая интересы и не мешая работе других. Как и большинство других php-фреймворков, Codeigniter 4 также придерживается этого шаблона проектирования и однажды, поняв принципы его работы, ты уже навряд ли сможешь отказаться от него.

Итак, разберём каждый из этих элементов немного подробнее.

Контроллеры

На смотря на то, что название шаблона проектирования MVC начинается с Модели и логичнее было бы начать разговор с неё, мы начнем именно с Контроллера. Если говорить о контроллерах в общих чертах, то это самые первые из компонентов, с которых, в приницпе, начинается работа любого приложения. Неважно, каков твой проект, большой или маленький, но хотя бы один контроллер в нём должен быть всегда! Не имея ни одного контроллера, ты не сможешь даже запустить свой проект, не говоря о том, чтобы что-то увидеть в окне своего браузера.

Задачи, которые ложаться на плечи контроллеров, достаточно велики. Приведу перечень наиболее важных:

  • Обработать полученные HTTP-запросы и вызвать необходимые методы (функции);
  • В зависимости от полученных данных, выполнить те или иные операции;
  • Подключить, если это необходимо, дополнительные функции и классы для выполнения требуемой задачи;
  • Проверить права доступа пользователей к запрашиваемой информации;
  • Посредством Моделей начать взаимодействие с базой данных;
  • Сформировать итоговые результаты в требуемом виде;
  • Передать готовые результаты в нужное Представление (html-файл) и вызвать запуск этого Представления.

и это лишь малая часть функций, которые выполняют Контроллеры.

Из приведенного перечня задач, мы можем сделать заключение, что Контроллеры являются как бы "виртуальными" объектами или интерфейсом, с которым взаимодействует пользователь напрямую. Ссылки на сайте, например интернет-магазина, являются хорошим примером этому. Нажал на одну ссылку или кнопку - положил товар в корзину, нажал на вторую - удалил товар из корзины и т.д. Каждая из ссылок - это и есть вызов того или иного контроллера с соответствующими параметрами. В самой же работе, Контроллеры являются посредниками или связующим звеном между Моделями и Представлениями.

По умолчанию, в Codeigniter 4 для контроллеров отведена специальная директория /app/Controllers, которая, после установки фреймворка, уже будет содержать несколько готовых Контроллеров, обеспечивающих первый запуск.

Модели

В общих чертах, простыми словами, Модели - это просто php-классы, которые отвечают исключительно за работу с базой данных и организуют единый (или общий) интерфейс взаимодействия с этой базой для всего проекта. Модель не должна и не может быть вызвана напрямую пользователем. Вызов любой Модели осуществляется только через Контроллер.

По умолчанию, в Codeigniter 4 для Моделей отведена специальная директория /app/Models и поскольку она попадает в общее пространство имён, ты вправе организовать свою собственную структуру директорий для хранения Моделей, в засимости от потребностей твоего проекта.

Представления

Представления являются простейшими файлами, предназначенными для внешнего оформления твоего приложения. Фактически это обычные страницы, которые содержат html код и немного php кода для вывода информации. В большинстве случаев это обычные переменные php или простой цикл, который перебирает значения и "рисует" таблицу с ними.

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

В процессе развития твоего проекта, количество файлов Представлений может стать очень большим. Поэтому, рекомендую с самого начала разработки проекта придерживаться ряда правил. Все Представления храни в специальной, предназначенной для Представлений директории /app/Views. Для каждого контроллера заведи отдельную директорию, внутри которой, для каждого метода Контроллера, создавай отдельный файл Представления. Например, у тебя есть Контроллер User.php, который содержит в себе метод с названием Profile. В этом случае, самым лучшим решением будет создать такую структуру: /app/Views/User/Profile.php. Добавив еще один метод в Контроллер, например editUser, создай еще одно Представление в директории этого же Контроллера, например /app/Views/User/EditUser.php и т.д.

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

Подведем итог

Чтобы окончательно сформировать общую картину в голове о шаблоне проектирования MVC и понять как происходит взаимодействие этих трёх компонентов между собой, я приведу пример. Там не будет никаких "тонкостей и правильностей". Он нужен лишь для того, чтобы понять всю логическую цепочку взаимодействия Контроллера-Модели-Представления.

Ты обычный пользователь, который зашел на сайт интернет-магазина по продаже одежды и нажал в разделе меню на пункт "Рубашки". Как только ты это сделал, происходит вызов Контроллера (его название нам сейчас не принципиально). Контроллер ищет внутри себя участок кода, который отвечает за "показ всех рубашек" и обращается к этому коду. Этот код понимает, что вся информация о рубашках хранится в базе данных и обращается к конкретному файлу (Модели), в котором хранится запрос к базе данных на получение этой информации. Далее, в работу вступает Модель. При запросе к базе данных, Модель учитывает параметр shirts (мы же рубашки ищем, верно?) и выбирает только ту информацию, которая относится к категории shirts. После этого, Модель возвращает назад в код Контроллера полученные данные. Код Контроллера, получив эти данные, "готовит" их и передает в отдельный файл Представления, после чего вызывает само Представление, которое и отобразит в окне браузера все рубашки, имеющиеся в магазине. Если пользователь захочет отфильтровать рубашки по определенному ценовому диапазону, тогда, по сути, произойдет вызов того же самого Контроллера, того же кода в нем, той же Модели, только сама Модель уже будет учитывать не только категорию shirts, но еще и указанный ценовой диапазон. Как только данные будут получены, код Контроллера снова передаст эту информацию в то же самое Представление, после чего вызовет его.

Теперь, надеюсь, ты осознаешь всё то удобство разработки, о котором я говорил в начале. Поплыл дизайн приложения? Идёшь в Представления и правишь недочеты в html или css коде, не видя вообще (практически) никакого php кода или запросов к базе данных. При нажатии на ссылку или кнопку происходит не то, что планировалось? Идёшь и ищешь ошибку в Контроллерах, не разгребая тонны html-тегов. Неверно сохраняется или извлекается информация из базы данных? Идёшь в Модели и работаешь исключительно с SQL запросами к базе данных, корректируя их так, как необходимо. Удобно? Несомненно!


Комментарии к разделу:

Пока ещё никто не оставил своего комментария. Оставить свой!

Добавить комментарий к статье:


Ваше имя:
Ваша почта:

  Закрыть