Серверная часть системы создания и управления сайтами

Дипломная работа - Компьютеры, программирование

Другие дипломы по предмету Компьютеры, программирование

Скачать Бесплатно!
Для того чтобы скачать эту работу.
1. Пожалуйста введите слова с картинки:

2. И нажмите на эту кнопку.
закрыть



ки к конкретному типу БД, потому что поддержка всех баз данных реализована через общий интерфейс. Поэтому при добавлении новой БД изменять логику Менеджера Хранилища не требуется, что в разы сокращает время разработки и отладки.

Описание методов интерфейса представлено в таблице 3.2.

 

Таблица 3.2 - Методы интерфейса IDbm

МетодОписание__construct ($host, $user, $password)Подключение к базе данных__destruct()Отключение от базы данныхRemoveDatabase ($db_name)Удаление базы данныхCreateDatabase ($db_name)Создание базы данныхSelectDatabase ($db_name)Выбор рабочей базы данныхExecQueryFromFile ($file_name)Выполнение sql-сценария из файлаAddData ($table_name, $values)Добавление строки данных в таблицуExecQuery($query)Выполнение sql-запросаUpdateData ($table_name, $new_data, $condition = NULL)Обновление существующих данныхGetData ($what, $from, $condition = NULL)Возвращение строки данныхRemoveData ($from, $condition = NULL)Удаление данныхGetAllData ($what, $from, $condition = NULL)Возвращение всех строк данныхGetCount ($from, $condition = NULL)Возвращение числа строк данных

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

 

Таблица 3.3 - Методы Генератора сайта

МетодОписаниеGeneratePage ($url_name, $page_data, $template_data, $old_url_name = FALSE)Компанует страницу из содержимого и шаблона и записывает готовую страницу в файловую системуRemovePage ($url_name)Удаляет страницуRemoveResourceFile($path)Удаляет файл ресурса

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

Рассмотрим на примере связь всех этих модулей между собой. Допустим, клиент хочет сохранить черновик страницы. Он обращается к Координатору с командой page_savedraft. Координатор обрабатывает запрос и вызывает метод Менеджера Хранилища SavePageDraft. Менеджер Хранилища обрабатывает данные и выбирает базу данных с помощью метода SelectDatabase Менеджера базы данных. Далее Менеджер Хранилища обновляет данные с помощью метода UpdateData Менеджера базы данных. Далее происходит публикация страницы. Для этого с помощью метода GetData Менеджер Хранилища производит выборку шаблона и страницы, и вызывает метод Генератора сайта GeneratePage, который обновляет страницу в файловой системе. В конце Координатор возвращает статус ОК, сигнализирующий об успешном выполнении команды. Описанный выше процесс изображен на рисунке 3.2. Пунктирный стрелки обозначают возврат результатов запросов к модулям. На их основе формируется возврат Координатора.

 

Рисунок 3.2 - Структура серверной части

 

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

 

2.2Структура базы данных

 

База данных была спроектирована на основе существующих в системе логических элементов: страниц (pages), шаблонов (templates), ресурсов (resources) и самого проекта (projects).

При проектировании учитывалась также возможность последующего расширения системы.

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

На основе этих рассуждений была предложена структура базы данных. Ее диаграмма сущность-связь предоставлена на рисунке 3.3. При этом наименование projectx означает кодовое имя проекта и не имеет отношения к базе данных как таковой.

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

 

Рисунок 3.3 - Диаграмма базы данных системы

Описание структуры всех таблиц базы данных представлено в таблицах 3.4 - 3.10.

Во главе структуры находится таблица projects. У каждого проекта есть уникальное имя, которое записывается в текстовое поле project_uid.

В каждом проекте присутствуют страницы. Они представлены таблицей pages. В поле page_uid содержится уникальное имя страницы. Project_id определяет к какому проекту относится данная страница. Поле page_url задает под каким именем будет видна страница в строке браузера. Поля generated_modification_time и generated_draft_uid используются для сохранения времени последней генерации данной страницы и имени последнего сгенерированного черновика. Они позволяют не генерировать данную страницу повторно в случае наличия самой последней версии.

У страницы предполагается наличие нескольких черновиков. Они хранятся в таблице page_drafts. Поле draft_uid представляет уни

s