Практически любая информационная система характеризуется наличием системы хранения и обработки данных.
Возьмем, к примеру, обычные веб-сайты.
Для их создания обычно используются какие-то готовые системы (фреймворки или готовые CMS), которые изначально уже содержат какую-то концепцию работы с данными, сложившуюся предметную область.
Обычно, если разработчик хочет добавить на сайт новостной раздел, он добавляет в интерфейс CMS компонент, информационный блок, шаблон и т.д. Суть всех этих конструкций одна — создать в базе данных сущность для хранения (или какого-то другого хранилища).
В результате имеется реляционная база данных и, зачастую, некий объектно-ориентированный орган, реализующий совокупность объект-атрибуты-свойства-методы - реализуется предметная область.
Ниже мы обсудим один из вариантов доменной архитектуры.
Статья основана на опыте работы в компании.
АДВ , который применяет подобные методы при разработке веб-проектов.
Сложность представленного материала позволяет понять его не только разработчикам программного обеспечения, но и веб-мастерам, которым необходимо периодически дорабатывать существующие веб-проекты, добавляя в них новые данные.
Простейшие системы позволяют лишь организовать репозиторий, к которому затем обращается разработчик и сам выполняет всю необходимую работу по обработке данных.
В таком хранилище есть только объект, поля и данные.
В более продвинутых системах между объектами появляются связи.
Следующий уровень разработки — взаимодействие объектов (триггеров, методов и т.п.
), а также наличие программной подсистемы, избавляющей разработчика от некоторых забот по обработке данных.
Представьте себе идеальное приложение, в котором все построено на хорошо функционирующем домене.
Его архитектор (обычно специалист по каким-то системам хранения данных) заранее знает будущее приложение и создает для него хранилище по такому принципу, который охватывает 2 из 3 уровней разработки приложения: уровень хранилища и уровень алгоритма.
Дальнейшее создание функционала веб-разработчиком — это лишь вопрос бизнес-задачи (отобразить все записи блога, выбрать все комментарии к текущей записи блога и т. д.).
И разработчику не очень важно знать, как именно организована структура хранения данных на уровне SQL (структура хранения данных реализуется в виде самих данных, реализована с помощью стандартных средств СУБД или смешанная).
Он оперирует понятиями предмет-признак.
Предметную область в этом случае можно представить в виде графика.
Помимо стандартных характеристик объекта (признаков (информации, связей) терминологическое поле имеет:
- можно организовывать не только связи, но и взаимодействия (триггеры);
- графические маршруты (закрытые, открытые, часто меняющиеся);
- устранение необходимости знать, как на самом деле выглядят таблицы SQL;
- методы (добавить пользователя, отправить письмо по почте и добавить что-нибудь в другой объект).
Объектная модель
Объектная модель должна позволять выбирать множество A на основе известных параметров B: A(B).Вот несколько практических примеров:
- список пользователей, возраст которых > 20: user(user.age> 20);
- список подарков для пользователей старше 20: подарки(user.age> 20).
В идеале система может также предоставить интерфейс, в котором архитектор может наглядно увидеть структуру создаваемого им хранилища данных.
Для реализации такой модели создается так называемый объектный сервер.
Это отдельное приложение, имеющее интерфейсы для взаимодействия с другими приложениями.
Объектный сервер знает о своих компонентах и определяет, какая информация у него была запрошена.
Клиентское приложение, в котором разработчик описывает свои запросы к базе данных, не знает структуры базы данных, но имеет механизмы, позволяющие запрашивать необходимую информацию с сервера объекта.
Рассмотрим пример, наша предметная область изображена в виде графика.
На графике описана ситуация с сотовой связью: оператор - регион - тариф - сим-карта (номер) - договор - телефон - бренд - человек - где зарегистрирован.
Пример запроса:
- регион(человек.
возраст> 20, бренд=Nokia);
- регион(человек.
возраст> 20).
Соединения
Клиентское приложение передает параметры объектов «Человек» и «Бренд» объектному серверу, который должен построить по ним соединение и сформировать список регионов, в которых проживают такие люди.Как мы видим из графика, существует несколько вариантов его обхода для выявления связей.
Для расчета последовательно строится дерево, корнем которого является искомый объект (Регион), а ветвями — все последовательно связанные объекты.
Построение происходит в несколько итераций от искомого объекта в глубь графа.
В нашем примере с деревом таких уровней 4. В дереве каждый объект участвует только один раз.
После строительства на необходимых узлах отмечаются заданные разработчиком параметры, а ненужные отсекаются.
В примере с выбором региона ветка «Контракт-Оператор» не требуется, поэтому она не учитывается.
А по настройкам «Бренд» и «Персона» объектный сервер точно сможет определить Регион.
Итак, мы выяснили, как строятся возможные пути между объектами для вычисления функции A(B).
Осталось понять, какой маршрут выбирает объектный сервер.
Здесь все очень просто: кратчайший маршрут выбирается исходя из весов участвующих в нем объектов.
Логично, что независимый объект имеет наибольший вес, равный 1. Связывающий объект имеет вес 1/2. Другие объекты хранения также имеют аналогичный вес.
Типы объектов
При проектировании систем, особенно тех, которые в дальнейшем будут постепенно развиваться, увеличивая функциональность, всегда есть опасность усложнить и захламить базу.В предметной области очень часто видоизменяются промежуточные связи, но существует основная терминологическая область, которая не меняется с течением времени.
Меняются связи и вспомогательные объекты.
При добавлении нового модуля наиболее эффективно строить его на базе того же физического хранилища данных, но использовать вместо них объекты-алиасы как базовые объекты, общие для всей системы в целом (например, пользователь, город и т.п.
).
.
) .
Это независимый объект на объектном сервере, полностью копирующий структуру и данные своего родителя.
Однако в структуре графа это независимые вершины.
В нашем примере мы не использовали псевдонимы.
Но существует так называемое кольцо, которое провоцирует объектный сервер строить соединения сразу по нескольким маршрутам.
Например, если разработчик захочет выполнить запрос Region(Person.age> 20), то объектный сервер будет вынужден взять сразу два маршрута, один из которых короткий, а второй более длинный.
Это, в свою очередь, увеличивает время и ресурсы, необходимые для завершения операций.
Архитектор базы данных должен по возможности избегать создания колец в процессе проектирования.
В этом ему могут помочь псевдонимы объектов или специальный параметр, который используется для обозначения объектов, которые являются конечными и не позволяют строить через себя сквозные соединения.
Архитектура также обеспечивает связывание объектов, которые помогают устранить связи «многие ко многим».
Конечно, алгоритмы объектных серверов не всегда могут выстраивать соединения максимально эффективно, а иногда они строятся совсем не так, как задумал архитектор.
Существуют также специальные параметры для принудительного включения или исключения объектов из соединения.
Кроме того, зачастую необходимо не просто указать наличие того или иного объекта в дереве соединений, но и более глубоко описать саму суть соединения.
В этом случае на помощь приходит инструмент, позволяющий ввести в алгоритм построения дерева специальные условия синтаксиса СУБД.
В зависимости от типа архитектуры возможно, что хранение и представление данных будут разными.
Те.
Существуют виртуальные объекты, которые не являются точной проекцией некоторых объектов в базе данных; у них может вообще не быть собственной таблицы в базе данных.
Это несколько шире, чем просто псевдонимы объектов.
Например, вычисляемый объект, аналог сущности VIEW в СУБД, содержащий поля, содержимое которых динамически рассчитывается на основе полей других объектов в том же хранилище.
выводы
Целью статьи было показать, что при разработке любой системы управления зачастую лучше думать не только о том, какие таблицы будут в базе данных и как они связаны, но и о том, какие инструменты предлагаются для работы с ними.Как разработчик веб-приложений может при этом сэкономить время? Такой подход позволяет строить большие, хорошо масштабируемые структуры данных с индивидуальной настройкой каждого объекта независимо от других.
И дело здесь не только в том, как красиво обернуть данные, но и в том, как упростить к ним доступ.
Эпилог
Описанная схема реализована в одном закрытом каркасе.Моцарт , используется компанией АДВ Я занимаюсь разработкой веб-проектов уже больше года.
В целом инструмент полностью оправдывает свое существование, ведь именно при создании сайтов упрощается значительная рутинная часть.
Кроме того, новому человеку довольно легко понять суть и быстро перейти от обучения к собственно разработке проектов.
В ближайшем будущем «Моцарт», скорее всего, будет опубликован в открытом доступе под одной из свободных лицензий.
Теги: #CMS #cmf #архитектура системы #предметная область #хранение данных #абстракция #реклама #разработка веб-сайтов
-
Разветвитель Последовательного Порта
19 Oct, 24 -
Качественный Интерфейс По Версии Microsoft
19 Oct, 24 -
Антиюзабилити Или Меня Бесит, Когда...
19 Oct, 24 -
Качество Сна
19 Oct, 24 -
Сервер Quake Iii На Телефонах Nokia
19 Oct, 24
