Модели, представления и контроллеры

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

Модели управляют данными приложения и помогают применять любые специальные бизнес-правила, которые может потребоваться приложению.

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

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

В своей основе контроллеры и модели — это просто классы, имеющие определенную задачу. Очевидно, они не единственный тип классов, которые можно использовать, но они составляют основу того, как этот фреймворк предназначен для использования. Они даже имеют назначенные каталоги в каталоге /app для хранения, хотя вы можете хранить их где угодно, при условии правильного именования. Мы более подробно обсудим это ниже.

Давайте подробнее рассмотрим каждый из этих трех основных компонентов.

Компоненты

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

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

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

Представления обычно хранятся в /app/Views, но могут быстро стать громоздкими, если их не организовать каким-либо образом. CodeIgniter не навязывает никаких организационных правил, но хорошим правилом является создание нового каталога в каталоге Views для каждого контроллера. Затем имена представлений должны соответствовать именам методов. Это делает их очень легкими для поиска позже. Например, профиль пользователя может отображаться в контроллере с именем User, и методом с именем profile. Вы можете сохранить файл представления для этого метода в /app/Views/User/Profile.php.

Такая организация отлично подходит в качестве базовой привычки. Иногда вам может потребоваться организовать её по-другому. Это не проблема. Пока CodeIgniter может найти файл, он может его отобразить.

Подробнее о представлениях

Модели

Задача модели — поддерживать один тип данных для приложения. Это могут быть пользователи, записи блога, транзакции и т. д. В этом случае задача модели состоит из двух частей: применять бизнес-правила к данным при извлечении или записи в базу данных; и обрабатывать фактическое сохранение и извлечение данных из базы данных.

Для многих разработчиков путаница возникает при определении бизнес-правил. Это просто означает, что любые ограничения или требования к данным обрабатываются моделью. Это может включать нормализацию сырых данных перед сохранением для соответствия корпоративным стандартам или форматирование столбца определенным образом перед передачей контроллеру. Хранение этих бизнес-требований в модели позволит избежать повторения кода в нескольких контроллерах и случайно пропустить обновление области.

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

Подробнее о моделях

Контроллеры

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

Другая задача контроллера — обработка всего, что связано с HTTP-запросами: перенаправлениями, аутентификацией, безопасностью веб-приложений, кодированием и т. д. Короче говоря, контроллер гарантирует, что пользователи имеют доступ, и получают необходимые данные в подходящем формате.

Контроллеры обычно хранятся в /app/Controllers, хотя они могут использовать пространства имен для группировки по мере необходимости.

Подробнее о контроллерах