Построение сложных систем

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

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

Этот список можно продолжить. И вы его продолжите сами, когда дойдете до середины пути (месяцев через восемь), после чего окажется, что выбранная архитектура ставит планку, выше которой прыгнуть уже нельзя.

COM технология, как проверенный временем подход разработки сложных систем, эту планку преодолевает. И хотя затраты на разработку будут выше (это мягко сказано), они окупают себя. Использование COM для работы с данными привело к формированию спецификации OLE DB, которая обобщает и приводит к единообразию работу с источниками информации. Это в глобальном масштабе. В локальном, применительно к реальным проектам, она позволяет решать перечисленные проблемы:

Единое подключение

Одним из сценариев работы приложения может быть такая последовательность событий:

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

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

• все детали реализации доступа к данным заключены в коробочке под названием OLE DB провайдер;
• все модули могут получить доступ к базе данных, при этом «размывается» граница между ними. Они все работают в одном контексте подключения.

Работа в одной транзакции

Наверное, имеет смысл привести реальный пример, где это необходимо.

Если структура объектов данных во многом пересекается, то имеет смысл создать маленькие и специализированные компоненты, которые могут работать только с одним типом информации. После этого их можно объединять в группы и получать составных редакторы, которые будут наполовину состоять из общих частей. Очевидно, что операции чтения/записи частей должны проходить в контексте одной транзакции. При чтении это дает гарантию единого «снимка» объекта, при записи - возможность фиксации или отмены изменений проведенных разными частями редактора (которые, возможно, даже не знают о существовании друг друга).

OLE DB провайдер предоставляет контекст транзакции (или сессию) в виде COM объекта. С его помощью (правильнее сказать, через него) вы подаете команды управления транзакцией. Надо заметить, что спецификация предусматривает обширный диапазон возможностей и режимов для транзакции. Возможно, их полный набор обеспечивают только Oracle и DB2. Создав с помощью источника данных компоненту сессии, вы можете передавать еe как обычный COM объект через границы модулей. Помимо управления транзакцией, эта компонента отвечает за создание команд для работы с данными. Очевидно, что эти команды будут работать в контексте сессии-родителя.

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

Результирующее множество

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

Выполнение скриптов

Сегодня построение гибких систем, которые смогут развиваться, достаточно сложно без поддержки скриптования. Создание и модификацию отчетов, изменение алгоритмов записи объекта в базу данных, гораздо проще выполнить, если ваша программа сможет выполнять код, предоставленный конечным пользователем. В настоящее время реализовать такую поддержку не очень сложно. Достаточно зайти на http://www.microsoft.com/downloads/details.aspx?FamilyID=d7e31492-2595-49e6-8c02-1426fec693ac&DisplayLang=en и скачать компоненту ScriptControl. Но если ваше приложение не было изначально соответствующим образом построено, скрипт не сможет получить доступ к данным через основное подключение программы. Конечно, можно заставлять его создавать отдельное подключение, однако этот подход пригоден только для формирования отчетов. Использование OLE DB, в этом отношении, даст вам фору перед конкурентами, поскольку такие компоненты для VB как ADO имеют интерфейсы для их подключения к OLE DB. А если программа уже работает через ADO, то проблемы передачи компонентов доступа к базе данных в скрипт вовсе исчезают.

Объектная модель базы данных

Все мы хотим создавать гибкие и масштабируемые системы. Мы бредим ими. Для информационных систем это означает безболезненное наращивание программного обеспечения и структуры базы данных. Хлипкий каркас того или иного приведет к плачевным результатам. И если с архитектурой программ вроде все понятно, и COM является ожидаемым светом в конце туннеля, то у баз данных такого стандарта нет. Хотя не все так плохо, как кажется. Одним из решений может быть применение объектного мышления для проектирования хранилища. Так, на www-4.ibm.com/software/developer/library/mapping-to-rdb/ приводятся некоторые идеи по этому поводу. При принятии на вооружение объектной стратегии проектирования базы данных, вы получаете возможность формировать пары (компонент-структура БД) которые становятся независимой единицей вашей системы. Создав достаточно продуманную архитектуру базы данных и используя COM технологию для программного обеспечения, вы обнаружите возможность повторного использования программных компонент для новых информационных структур. Использование OLE DB в качестве средства доступа этих компонент к информации, позволит перенести преимущества компонентной модели на архитектуру вашей базы данных.

Публикация баз данных в Internet

Одна из сфер современных применений OLE DB провайдера совместно с компонентами ADO - это их использование для публикации данных в WWW через ASP. Мы не будем здесь описывать и рассказывать, что и как для этого делается, а просто дадим ссылку на www.activeserverpages.ru