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

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

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

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

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

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

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

Компоненты

Просмотры

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

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

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

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

Узнать больше о просмотрах

Модели

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

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

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

Узнать больше о моделях

Контроллеры

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

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

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

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