2. Проектирование схемы базы данных

В качестве СУБД используется MySQL. Физическая схема связей служебных сущностей фреймворка CodeIgniter представлена на рисунке 4. Content Types Framework сохраняет информацию о моделях в таблицу contenttypes, а именно: название приложения, название модели и тип.

CodeIgniter использует миграции для переноса изменений в моделях (добавление поля, удаление модели и т.д.) на структуру базы данных. Миграции создавались в основном для автоматической работы. CodeIgniter предоставляет session framework, поддерживающую анонимные и пользовательские сессии. Session framework позволяет хранить произвольные данные для каждого посетителя. Данные сеанса хранятся на стороне сервера, а файлы cookie содержат session ID, если не используется обработчик сессий на основе файлов cookie. Промежуточное подпрограммное обеспечение управляет отправкой и получением файлов cookie. Обработчик сессий по умолчанию хранит данные сессии в базе данных

Физическая схема базы данных приложения pizzashop отображена на рисунке 4.

Рисунок 4  Физическая схема базы данных приложения bookshop

Одной из основных сущностей в системе является клиент (user). У него есть следующие поля: идентификатор, имя, фамилия, адрес, e-mail, телефон.

Другой основной сущностью является товар (book). Сущность товар состоит из полей: идентификатор, название, описание, цена и изображение.

Клиент и товар связаны с заказами. Сущность заказ (orderr) состоит из полей: идентификатор, идентификатор клиента, статус заказа и комментарий.

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

2. Архитектура CodeIgniter приложения

Архитектура Django похожа на «Модель-Представление-Контроллер» (MVC). Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Представление, а презентационная логика представления реализуется уровнем шаблонов. Из-за этого уровневую архитектуру Django часто именуют «Модель-Шаблон-Представление» (MTV), которые можно использовать независимо друг от друга. Структура MTV CodeIgniter — это фреймворк написанный на PHP. Первый публичный релиз CI состоялся в 2006 году (7 лет назад). Он быстро набирал популярность благодаря своей простоте, и быстроте. На данный момент актуальная версия 2.1.3. CodeIgniter использует MVC архитектуру, что позволяет всё разложить по полочкам. Ниже вы можете увидеть процесс работы CI. Имеет поддержу библиотек, хелперов, хуков. Также имеется встроенная система кэширования.

Н а рисунке 5 представлена архитектура CodeIgniter приложения

Рисунок 5 – архитектура CodeIgniter приложения

Как показано на рисунке, всякий раз, когда запрос приходит в CodeIgniter, он сначала переходит на страницу index.php .

На втором этапе маршрутизация решает, передавать ли этот запрос шагу 3 для кэширования или передавать этот запрос шагу 4 для проверки безопасности.

Если запрашиваемая страница уже находится в режиме кэширования, служба маршрутизации передаст запрос этапу 3, а ответ вернется к пользователю.

Если запрашиваемая страница не существует в кэшировании, то служба маршрутизации передает запрашиваемую страницу на шаг 4 для проверки безопасности.

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

Вид отобразит страницу с доступными данными и передаст ее для кэширования. Поскольку запрашиваемая страница ранее не кэшировалась, поэтому на этот раз она будет кэширована в Caching , чтобы быстро обработать эту страницу для будущих запросов.

На втором этапе маршрутизация решает, передавать ли этот запрос шагу 3 для кэширования или передавать этот запрос шагу 4 для проверки безопасности.

Если запрашиваемая страница уже находится в режиме кэширования, служба маршрутизации передаст запрос этапу 3, а ответ вернется к пользователю.

Если запрашиваемая страница не существует в кэшировании, то служба маршрутизации передает запрашиваемую страницу на шаг 4 для проверки безопасности.

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

Вид отобразит страницу с доступными данными и передаст ее для кэширования. Поскольку запрашиваемая страница ранее не кэшировалась, поэтому на этот раз она будет кэширована в Caching, чтобы быстро обработать эту страницу для будущих запросов.