Целью данной работы является анализ методов проектирования приложений использующих базу данных в качестве источника данных. Таким образом, исследования данной работы делает упор не на проектирование БД по какой-то конкретной тематике, а, прежде всего, отвечает на вопрос о том, как необходимо проектировать качественные приложения, использующие базы данных в качестве источника данных.
Критериями качества при проектировании подобного рода систем являются[1]:
-построение системы с любым уровнем сложности бизнес-логики, сохраняя при этом четкую структурированность системы;
-возможность широкого расширения функциональности системы по ходу дальнейшего жизненного цикла продукта без существенного перепроектирования системы, простота поддержания системы;
-гибкое поддержание принципов распределения программных компонентов и данных (например, возможности быстрого перевода системы на модель функционирования «клиент-сервер» и наоборот, разработка параллельно нескольких интерфейсов к системе, в том числе, и Web-интерфейса);
-четкая структурированность бизнес-логики;
-возможность параллельной работы целых групп разработчиков над различными аспектами приложения и быстрое согласование результатов их работы.
1. Трехслойная архитектура. Определение.
3х уровневая архитектура подразумевает под собой разделение всей системы на 3 слоя[2]:
-Слой «представления» (или «вид», “View Layer”) - охватывает все, что имеет отношение к общению пользователя с системой. Этот слой может быть настолько простым как командная строка или тестовое меню, но сегодня пользователю, скорее всего, придется иметь дело с графическим интерфейсом, оформленным в виде(Windows, Swing и т.п.) или основанным на HTML. К главным функциям слоя представления относятся отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес-логики) и источника данных.
-Слой источника данных(“Data Source Layer”) — это подмножество функций, обеспечивающих взаимодействие со сторонними системами, представляющими, как правило, бизнес-логику, которые выполняют задания в интересах приложения. Код этой категории несет ответственность за мониторинг транзакций, определение структур передачи данных между бизнес-логикой и источником данных, а также, самое главное, данный слой отвечает за предоставление интерфейса для необходимых операций взаимодействия внешних систем с источником данных. Для большинства приложений основная часть логики источника данных сосредоточена в коде СУБД.
-Слой логики домена (бизнес-логика или логика предметной области, “Domain Layer”) описывает основные функции приложения, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а также передача информации слою источника данных.
Упрощенная схема приложения при использовании 3х-слойной архитектуры показана на рис. 1.
Рис. 1 - Упрощенная схема приложения при использовании 3х-слойной архитектуры
2. Принципы организации Model Layer (бизнес - логики приложения)
2.1 Сценарий транзакции (Transaction script)
Сценарий транзакции[2] организует логику модели в виде набора процедур-транзакций, каждая из которых обращается к базе данных напрямую. Основной недостаток данного решения состоит в том, что оно неприемлемо для описания сложной бизнес-логики и особенно восприимчиво к эффектам повторения фрагментов кода.
2.2 Модель предметной области (Domain Model)
В своих наихудших проявлениях бизнес-логика[3] бывает чрезвычайно сложной с множеством правил, условий, оговаривающих различные варианты использования и особенности поведения системы. Для облегчения именно таких трудностей и предназначен объектно-ориентированный подход. Реализация модели предметной области означает пополнение приложения целым слоем, сетью взаимосвязанных объектов, описывающих различные стороны определенной предметной. Одни объекты призваны имитировать элементы данных, которыми оперируют в этой области, а другие должны формализовать те или иные бизнес-правила. Функции тесно сочетаются с данными, которыми они манипулируют.
2.3 Модуль таблицы (Table Module)
Типовое решение модуль таблицы[2] предусматривает создание по одному классу на каждую таблицу базы данных, и этот единственный класс инкапсулирует в себе всю логику обработки данных таблицы. Основное отличие модуля таблицы от модели предметной области в сочетании элементов данных и функций обрабатывающих их. Так, например, если приложение обслуживает множество заказов, в соответствии с моделью предметной области придется сконструировать по одному объекту на каждый заказ, а при использовании модуля таблицы понадобиться всего один объект, представляющий одновременно логику работы с каждым заказом.
2) администратор кластера (Cluster Administrator) – программа, запускающаяся на главном, фронтальном компьютере кластера и отвечающая за распределение вычислительных ресурсов кластера между заявками от программ-клиентов кластера;
Литература
1. Гамма Э., Хелм Р. и др. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2001. – 378 с.
2. Фаулер М. Архитектура корпоративных программных приложений.: -М.: Издательский дом «Вильямс», 2006.-544 с.
3. Г.Буч, Дж.Рамбо, А. Джекобсон Язык UML. Руководство пользователя. – М.:ДМК Пресс, 2004.-432с.