Анализ учета и исполнение заявок ремонта оргтехники. Часть 2.

Страницы:   1   2   3

---

3.1 Выбор архитектуры ИС

 

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

Архитектура «Клиент-сервер». Клиент-сервер — это не только архитектура, это — новая парадигма, пришедшая на смену устаревшим концепциям. Суть ее заключается в том, что клиент (исполняемый модуль) запрашивает те или иные сервисы в соответствии с определенным протоколом обмена данными. При этом, в отличие от ситуации с файловым сервером, нет необходимости в использовании прямых путей операционной системы: клиент их «не знает», ему «известны» лишь имя источника данных и другие специальные сведения, используемые для авторизации клиента на сервере. Сервер, который физически может находиться на том же компьютере, а может — на другом конце земного шара, обрабатывает запрос клиента и, произведя соответствующие манипуляции с данными, передает клиенту запрашиваемую порцию данных, как это показано на рисунке 3.

В рамках направления «клиент-сервер» существуют два основных «диалекта»: «тонкий» и «толстый» клиент.

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

Преимущества «тонких» клиентов [3]:

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

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

Преимущества «толстых» клиентов:

• Не требуется высокопроизводительный сервер, так как клиент сам выполняет большую часть обработки данных. Это приводит к значительному удешевлению серверов;
• Работа в автономном режиме. Как правило, таким клиентам не требуется постоянное соединение с центральным сервером;
• Большая гибкость. Некоторые программные продукты проектируются для компьютеров, имеющих свои локальные ресурсы. Запуск подобной программы на тонком клиенте может быть затруднителен или невозможен.

 

Достоинство архитектуры — переносимость серверной компоненты на серверы различных производителей: все промышленные серверы баз данных реляционного типа поддерживают работу со стандартизованным языком манипулирования данными SQL, но внутренний встроенный язык обработки данных, необходимый для реализации логики обработки на сервере у каждого из серверов свой [4].

Трехслойная архитектура. Базируется на дальнейшей специализации компонент — архитектуры: клиент занимается только организацией интерфейса с пользователем, сервер баз данных — только стандартизованной обработкой универсалам данных. Для реализации логики обработки данных архитектура предусматривает отдельный слой — слой бизнес-логики. Этот слой может представлять собой либо выделенный сервер (сервер приложений), либо размещаться на клиенте в качестве динамической библиотеки. Данная архитектура позволила соединить достоинства тонкого и толстого клиентов: хорошая переносимость соединяется в ней с невысокими требованиями к клиенту [5].

С развитием интернет-технологий появилась разновидность трехслойной архитектуры на основании использования web-технологий [6] . В этой разновидности роль сервера приложений играет web-сервер, а в качестве клиента используется стандартный web-браузер. На рисунке 4 показана ситуация с использованием различных серверов для хранения баз данных и приложений, которые могут географически располагаться на разных концах земного шара и представлять собой не один десяток компьютеров. В моём случае веб-сервер и сервер баз данных могут располагаться на одном компьютере.

Достоинства — в пониженных требованиях к клиенту и в легкой встраиваемости данной архитектуры в мировые информационные сети.

 

Основной недостаток — известные ограничения, накладываемые на интерфейс пользователя web-браузерами.

С помощью архитектуры SOA реализуются три аспекта ИТ-сервисов, каждый из которых способствует получению максимальной отдачи от ИТ в бизнесе [7]:

• сервисы бизнес-функций. Суть этих сервисов заключается в автоматизации компонентов конкретных бизнес-функций, необходимых потребителю;
• сервисы инфраструктуры. Данные сервисы выполняют проводящую функцию, посредством платформы, через которую поставляются сервисы бизнес-функций;
• сервисы жизненного цикла. Эти сервисы являются своего рода «обёрткой», которая в большинстве случаев поставляет ИТ-пользователям «настоящие сервисы». Сервисы жизненного цикла отвечают за дизайн, внедрение, управление, изменение сервисов инфраструктуры и бизнес-функций.

Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных элементов системы. Для взаимодействия компонентов используется сравнительно небольшой набор простых интерфейсов, которые обладают только самой общей семантикой и доступны всем провайдерам и потребителям. Через эти интерфейсы (рисунок 5) передаются сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для приложений, описывается непосредственно в этих сообщениях [8].

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

Архитектура веб-сервисов также является сервисно-ориентированной. Более того, веб-сервисы — это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются на интернет-протоколах (HTTP, FTP, SMTP, TCP), а все сообщения описываются в формате XML.

 

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

Вот шесть механизмов, с помощью которых поддерживается SOA-политика:

• операционная модель жизненного цикла SOA;
• организация SOA;
• SOA-процесс;
• портфель активов для сервисной интеграции в SOA;
• инструментарий SOA;
• SOA-технологии.

Эти механизмы используются обоими подходами к разработке и управлению SOA. Первый подход – это управление SOA по типу «сверху вниз». Он подразумевает, что управление по своей сути является стратегическим и начинается с модели и определённых проектов. Продвигаясь вниз, «стратегическое управление» определяет людей, процессы, сервисы, инструменты и технологии, которые будут привлекаться для поддержки корпоративного SOA-проекта. Второй подход – «снизу вверх» — соответственно подразумевает «тактическое управление», которое, наоборот, строит SOA-проект на основе создаваемых технологий, инструментов и сервисов. Большинство предприятий идет по пути «снизу вверх», начиная с конкретных сервис-ориентированных шагов, направленных на определённые предметные области. Очень редко встречаются организации, в которых создание стратегии первично по отношению к созданию необходимых отделов и бизнес-подразделений, первоначальных SOA-технологий и инструментария. Такой подход в целом только усложняет процесс налаживания управления SOA.

Автоматизированные учетные системы предприятия, как правило, являются многопользовательскими. Их архитектура позволяет различным пользователям со своих рабочих компьютеров одновременно получать доступ к информации, хранящейся в системе. Такие системы построены по технологии «клиент–сервер». В моём случае клиентами системы являются сотрудники отдела технической поддержки филиала предприятия и начальники информационно технических отделов его подразделений [10].

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

Поэтому, для решения задач автоматизации учета построение распределенной системы с ресурсоемким клиентским ПО не является существенно необходимым. Гораздо более актуально снижение затрат на администрирование, обеспечение защиты информации, целостности данных и непрерывности работы. Существующие Web-сервисы не отвечают потребностям и целям, преследуемым предприятием, поэтому было принято решение ориентироваться на Web [11].

Опыт построения ИС по такой технологии широко применяется и занимает лидирующие позиции в России среди ИС. Примером реализации этого подхода является Naumen Service Desk — информационная система для ИТ-подразделений и сервисных компаний (http://www.naumen.ru/go/products /nausd). Она так же построена на основе трехзвенной архитектуры. Интерфейсы пользователя и администратора полностью web-ориентированы. Для работы пользователю необходим лишь браузер. На рисунке 6 эта архитектура показана применительно к разрабатываемой мной автоматизированной информационной системе управления исполнением заявок по ремонту оргтехники (АИС УИЗРО).

 

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

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

Рассмотрим более подробно инструментарий построения АИС.

 

3.2 Шаблон проектирования

 

Шаблоны проектирования (паттерн, англ. design pattern) — это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения [12]. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях.

Объектно-ориентированные шаблоны зачастую показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. Алгоритмы не рассматриваются как шаблоны, так как они решают задачи вычисления, а не проектирования.

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

Правильно сформулированный паттерн проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова. В отличие от идиом, шаблоны независимы от применяемого языка программирования.

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

Model View Controller (MVC, управление видом модели) является одним из шаблонов архитектуры ПО. В сложных компьютерных приложениях, которые должны предоставлять пользователю большой объем данных, разработчик часто стремится разделить обработку данных и разработку пользовательского интерфейса так, чтобы изменения интерфейса не влияли на управление данными и данные могли быть реорганизованы без изменения интерфейса. Схема MVC решает эту проблему, отделяя доступ к данным и бизнес-логику от отображения данных и действий пользователя при помощи промежуточного компонента контроллера. Таким образом, модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты [13].

Модель обеспечивает хранение и представление информации, с которой работает приложение. Способ организации информации определяется особенностями предметной области. Многие приложения используют постоянный механизм хранения данных (такой, как БД). Однако в самом шаблоне MVC не определяется способ доступа к данным, поскольку подразумевается, что он определяется в модели.

Вид, как правило, представляет собой интерфейс пользователя. Он выполняет функции представления данных модели в виде, удобном для обработки. Для одной модели может одновременно существовать несколько видов.

Контроллер обрабатывает данные, отвечает на события, как правило, пользовательские действия, и может вносить изменения в модель.

Хотя MVC реализуется по-разному, обработка данных обычно происходит следующим образом [14]:

• Пользователь производит некоторое действие в интерфейсе системы (например, нажимает кнопку или изменяет значение поля в форме);
• Контроллер обрабатывает событие, полученное от пользовательского интерфейса, часто посредством вызова определенного обработчика;
• Контроллер обращается к модели, обновляя данные в соответствии с действиями пользователя;
• Вид обновляет пользовательский интерфейс. Данные для этого вид получает из модели посредством контроллера;
• Пользовательский интерфейс ожидает дальнейших действий пользователя, которые запустят цикл снова.

Стандартную схему архитектуры «Модель-Вид-Контроллер» можно увидеть на рисунке 7. Важно отметить, что вид и контроллер зависят от модели. Однако модель не зависит ни от вида, ни от контроллера. Это одно из ключевых достоинств подобного разделения. Оно позволяет строить модель независимо от визуального представления. Разделение моделей и видов в MVC способствует упрощению проектирования архитектуры системы и повышению гибкости.

 

Данная схема широко используется при построении web-приложений.

 

3.3 Реализация хранилища данных

 

Для хранения информации уже давно и успешно применяется реляционная модель данных. PostgreSQL — свободная объектно-реляционная система управления базами данных.

PostgreSQL является свободной альтернативой коммерческим СУБД (таким как Oracle Database, Microsoft SQL Server, IBM DB2, Informix и СУБД производства Sybase).

Она базируется на языке SQL и поддерживает многие из возможностей стандарта SQL:2003 (ISO/IEC 9075). Ограничения существующие в PostgreSQL на сегодняшний день приведены в таблице 1 [15].

Сильными сторонами PostgreSQL считаются:

• поддержка БД практически неограниченного размера;
• мощные и надёжные механизмы транзакций и репликации;
• наследование;
• легкая расширяемость.

Таблица 1 – Ограничения в PostgreSQL

 

Функции являются блоками кода, исполняемыми на сервере, а не на клиенте БД. Хотя они могут писаться на чистом SQL, реализация дополнительной логики, например, условных переходов и циклов, выходит за рамки собственно SQL и требует использования некоторых языковых расширений. Функции могут писаться с использованием одного из следующих языков:

• встроенный процедурный язык PL/pgSQL, во многом аналогичный языку PL/SQL, используемому в СУБД Oracle;
• скриптовые языки — PL/Lua, PL/LOLCODE, PL/Perl, plPHP, PL/Python, PL/Ruby, PL/sh, PL/Tcl и PL/Scheme;
• классические языки — C, C++, Java (через модуль PL/Java);
• статистический язык R (через модуль PL/R).

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

Функции могут выполняться как с правами их создателя, так и с правами текущего пользователя.

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

Триггеры определяются как функции, инициируемые DML—операциями. Например, операция INSERT может запускать триггер, проверяющий добавленную запись на соответствия определённым условиям. При написании функций для триггеров могут использоваться различные языки программирования.

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

Механизм правил (rules) представляет собой механизм создания пользовательских обработчиков не только DML-операций, но и операции выборки. Основное отличие от механизма триггеров заключается в том, что правила срабатывают на этапе разбора запроса, до выбора оптимального плана выполнения и самого процесса выполнения. Правила позволяют переопределять поведение системы при выполнении SQL-операции к таблице. Хорошим примером является реализация механизма представлений (англ. views): при создании представления создается правило, которое определяет, что вместо выполнения операции выборки к представлению система должна выполнять операцию выборки к базовой таблице/таблицам с учетом условий выборки, лежащих в основе определения представления. Для создания представлений, поддерживающих операции обновления, правила для операций вставки, изменения и удаления строк должны быть определены пользователем.

В PostgreSQL имеется поддержка индексов следующих типов: B-дерево, хэш, R-дерево, GiST, GIN. При необходимости можно создавать новые типы индексов, хотя это далеко не тривиальный процесс. Индексы в PostgreSQL обладают следующими свойствами:

• возможен просмотр индекса не только в прямом, но и в обратном порядке — создание отдельного индекса для работы конструкции ORDER BY … DESC не нужно;
• возможно создание индекса над несколькими столбцами таблицы, в том числе над столбцами различных типов данных;
• индексы могут быть функциональными, то есть строиться не на базе набора значений некоего столбца/столбцов, а на базе набора значений функции от набора значений;
• индексы могут быть частичными, то есть строиться только по части таблицы (по некоторой её проекции); в некоторых случаях это помогает создавать намного более компактные индексы или достигать улучшения производительности за счет использования разных типов индексов для разных (например, с точки зрения частоты обновления) частей таблицы;
• планировщик запросов может использовать несколько индексов одновременно для выполнения сложных запросов.

PostgreSQL поддерживает одновременную модификацию БД несколькими пользователями с помощью механизма Multiversion Concurrency Control (MVCC). Благодаря этому практически отпадает нужда в блокировках чтения, и принцип ACID соблюдается очень эффективным способом.

PostgreSQL поддерживает большой набор встроенных типов данных:

• численные типы;
• целые;
• с фиксированной точкой;
• с плавающей точкой;
• денежный тип (отличается специальным форматом вывода, а в остальном аналогичен числам с фиксированной точкой с двумя знаками после запятой);
• символьные типы произвольной длины;
• двоичные типы (включая BLOB);
• типы «дата/время» (полностью поддерживающие различные форматы, точность, форматы вывода, включая последние изменения в часовых поясах);
• булев тип;
• перечисление;
• геометрические примитивы;
• сетевые типы;
• IP и IPv6—адреса;
• CIDR—формат;
• МАС—адрес;
• UUID—идентификатор;
• XML—данные;
• массивы;
• OID—типы;
• псевдотипы.

Более того, пользователь может самостоятельно создавать новые требуемые ему типы и программировать для них механизмы индексирования с помощью GiST.

PostgreSQL может быть расширен пользователем для собственных нужд практически в любом аспекте. Есть возможность добавлять собственные:

• преобразования типов;
• типы данных;
• домены (пользовательские типы с изначально наложенными ограничениями);
• функции (включая агрегатные);
• индексы;
• операторы (включая переопределение уже существующих);
• процедурные языки.

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

Данный функционал в текущее время не является полностью завершённым. Однако он достаточен для практического использования.

Прочие возможности:

• соблюдение принципов ACID;
• соответствие стандартам ANSI SQL-92 и SQL-99;
• поддержка запросов с OUTER JOIN, UNION, UNION ALL, EXCEPT и подзапросов;
• последовательности;
• контроль целостности;
• репликация;
• поддержка Юникода;
• поддержка регулярных выражений в стиле Perl;
• встроенная поддержка SSL и Kerberos;
• блокировки точнее, чем на уровне записи;
• подгружаемые расширения, поддерживающие SHA1, MD5, XML и другую функциональность (API открыт);
• средства для генерации совместимого с другими системами SQL-кода и импорта из других систем.

Согласно результатам автоматизированного исследования различного ПО на предмет ошибок, в исходном коде PostgreSQL было найдено 20 проблемных мест на 775 000 строк исходного кода (в среднем, одна ошибка на 39 000 строк кода). Для сравнения: MySQL — 97 проблем, одна ошибка на 4 000 строк кода; FreeBSD (целиком) — 306 проблем, одна ошибка на 4 000 строк кода; Linux (только ядро) — 950 проблем, одна ошибка на 10 000 строк кода.

Исходя из описанных выше характеристик [16] в качестве сервера баз данных я решил использовать PostgreSQL.

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

Реляционные БД используют набор таблиц, представляющих данные простых типов. Дополнительная или связанная информация хранится в других таблицах. Часто для хранения одного объекта в реляционной БД используется несколько таблиц, что требует применения сложных запросов для получения всей относящейся к объекту информации и ее обработки. В результате увеличивается сложность программного кода, в нем легче допустить ошибку. Одним из решений данной проблемы является ORM (Object-relational mapping) – технология программирования, связывающая БД с концепциями объектно-ориентированных языков программирования, создавая виртуальную объектную БД.

С применением ORM система с точки зрения программиста выглядит как постоянное хранилище объектов, позволяя создавать объекты и работать с ними, автоматически сохраняя их в реляционной БД.

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

Однако ORM избавляет программиста от написания большого количества кодов, тем самым значительно повышая его производительность [18]. Кроме того, большинство современных реализаций ORM позволяют программисту при необходимости самому жестко задать код SQL-запросов, который будет использоваться при тех или иных действиях (сохранение в БД, загрузка, поиск) с постоянным объектом.

 

3.4 Каркас приложения

 

Application Framework — каркас приложения (открытая инфраструктура приложения). Это программный framework, который используется, чтобы обеспечивать выполнение стандартной структуры приложения для определённой операционной системы. Каркасы приложения стали популярны с появлением GUI(Graphical user interface — графический пользовательский интерфейс (ГПИ), который имел тенденцию к распространению стандартой структуры для приложений. С их использованием стало гораздо проще создавать средства для автоматического создания ГПИ, так как структура внутренней реализации кода приложения стала известна заранее. Для обеспечения каркаса обычно используются техники объектно-ориентированного программирования, например части приложения могут наследоваться от базовых классов фреймворка [19].

Существует ряд некоммерческих продуктов с открытым программным кодом, которые можно использовать в качестве каркаса для построения web-приложений. Их использование позволяет программисту не заниматься низкоуровневым программированием. Применение таких средств делает код более простым и ясным, что способствует уменьшению количества ошибок в программе и сокращает время на разработку.

После изучения и сравнения таких средств создания web-приложений было решено использовать ряд компонентов свободного кроссплатформенного программного каркаса Django [20], основыванного на технологии ORM и реализующего архитектуру MVC(MTV). Он построен на языке Python, который широко используется при разработке web-приложений благодаря своей гибкости и универсальности. Django проектировался для работы под управлением Apache с модулем mod python и с использованием PostgreSQL в качестве базы данных.

Некоторые возможности Django:

• ORM, API доступа к БД с поддержкой транзакций;
• встроенный интерфейс администратора, с уже имеющимися переводами на многие языки;
• диспетчер URL на основе регулярных выражений;
• расширяемая система шаблонов с тегами и наследованием;
• система кеширования;
• интернационализация;
• подключаемая архитектура приложений, которые можно устанавливать на любые Django-сайты;
• «generic views» — шаблоны функций контроллеров;
• авторизация и аутентификация, подключение внешних модулей аутентификации: LDAP, OpenID и проч;
• система фильтров («middleware») для построения дополнительных обработчиков запросов, как например включённые в дистрибутив фильтры для кеширования, сжатия, нормализации URL и поддержки анонимных сессий;
• библиотека для работы с формами (наследование, построение форм по существующей модели БД);
• встроенная автоматическая документация по тегам шаблонов и моделям данных, доступная через административное приложение.

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

С включением поддержки WSGI, Django может работать под управлением FastCGI, mod_wsgi или SCGI на Apache и других серверах (lighttpd, nginx,…) и подключаться к СУБД MySQL, SQLite и Oracle.

В составе Django присутствует собственный веб-сервер для разработки [21]. Сервер автоматически определяет изменения в файлах исходного кода проекта и перезапускается, что очень ускоряет процесс разработки на Python. Но при этом он работает в одно-потоковом режиме и пригоден только для процесса разработки и отладки приложения.

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

Логика приложения может быть распределена между контроллером, моделью и видом различными способами. Если требуется обеспечить наибольшую гибкость и универсальность, есть смысл придерживаться подхода, при котором бизнес-логика и семантика прикладной системы помещены в БД. Такой подход (Database-centric architecture) широко применяется при разработке web-приложений с использованием динамических языков программирования. Его преимущества [21]:

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

Для реализации подобной архитектуры требуется описать в БД семантику и логику прикладной программы. В созданном инструментарии содержатся средства семантической разметки структуры БД и средства вызова хранимых процедур БД из пользовательского интерфейса.

Django, объеденяя в себе все возможности ORM и MVC, а так же за счёт своей модульности с лёгкостью позволяет решить поставленную передо мной задачу.

Django реализация ORM имеет возможность анализировать БД при ее подключении. При этом автоматически определяются состав и атрибуты полей таблиц, а также установленные связи между таблицами. Это дает возможность создания приложения, автоматически настраивающегося согласно декларированной структуре БД. Всю необходимую дополнительную информацию, описывающую семантику объектов и их связей, в том числе права доступа к данным, можно хранить либо в полях комментариев, либо в служебных таблицах БД.

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

Логику приложения в БД можно реализовать при помощи триггеров и хранимых процедур. Преимущество триггеров в том, что их вызов привязан к действию с данными, поэтому не требуется создание дополнительного механизма их вызова. Однако функциональность триггеров в MySQL ограничена, в частности, в триггерах запрещена рекурсия, что может стать серьезной проблемой при разработке эффективного прикладного решения. Поэтому был создан механизм вызова хранимых процедур БД. При операции с данными проверяется наличие в БД соответствующих процедур и вызывается их выполнение. Это позволило реализовать анализ и обработку вводимых данных, поддержание логической целостности информации и другие необходимые функции.

---

Страницы:   1   2   3