Создание коммерческих приложений на Microsoft Access

В статье рассмотрены способы создания и распространения программ, разработанных в среде Microsoft Access. Статья написана на основании семилетнего опыта разработки на Access VBA (версии 97-2002) автором лично, а также сотрудниками Консультационной группы Воронов и Максимов.

Введение

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

Access, как система управления базами данных, позиционируется в качестве средства управления данными конечным пользователем без привлечения программиста. Это безусловно является плюсом Access как программы, но ведет к активному неприятию его IT-профессионалами.

В следствие вышеизложенного, программы на Access/VBA пытаются писать люди, не имеющие достаточного опыта и навыка программирования. Такие разработки даже распространяются на коммерческой основе, а также выкладываются для свободного доступа в интернете. Профессиональный программист приходит в ужас при ознакомлении с кодом таких «программ» и распространяет свое мнение на средство разработки.

Так называемая «литература для чайников» только усиливает впечатление об Access как несерьезной системе. Преподавание разработки баз данных в ВУЗах зачастую также основано на подобных книгах и пособиях.

Столкнувшись в первый раз с необходимостью написания собственной программы на Access, профессионал объектно-ориентированного программирования (C++, Delphi) часто не знает с какой стороны подойти к процессу разработки, так как Visual Basic for Application предлагает своеобразный набор средств работы с классами. Тут необходимо заметить, что программисту, который предварительно глубоко изучил COM-программирование Windows будет гораздо легче понять способы взаимодействия классов, ссылок и т.п.

Access предлагает совершенно нестандартный по отношению к распространенным средствам разработки подход к программированию пользовательского интерфейса (формы, отчеты). Это может вызвать трудность для понимания даже для опытных программистов, и даже разработчиков на родственном языке Visual Basic. Основополагающий момент здесь – это то, что элементы управления (контролы) Access не являются Windows-контролами и не имеют контекста окна (hWnd). Хотя эти контролы и выглядят как стандартные, а также имеют наборы свойства и событий, по существу они являются просто картинки, прорисовываемые приложением на форме. Также нетрадиционный подход реализован для списков и форм с данными. Контролы, а также сама форма, всегда имеет источник данных, который может настраиваться динамически без создания дополнительных компонентов. Зачастую, не разобравшись в подобных особенностях языка и среды разработки, программисты ссылаются на «неправильность» всей системы.

Также многие обвиняют Access в недостаточной защищенности программ и данных от несанкционированного доступа. Пожалуй, это единственный момент с которым можно согласиться. То есть, правильнее сказать, что для обеспечения защиты данных могут потребоваться дополнительные действия, которые в принципе не требуются при использование других систем разработки. Подробнее на эту тему – см. главу «Ограничения».

С другой стороны, я согласен с тем, что изначально Access предназначался для создания локальных приложений и не являлся в полной мере средством разработки коммерческих программных продуктов. Тот кто работал с Access 2.0, я думаю, подтвердит, что с точки зрения программиста система была очень неудобной. В защиту могу сказать лишь то, что предок современного Delphi, версии 1.0 – мне довелось с ним работать – тоже был далек от идеала. Возможности текущих версий Access (версии 2000 и далее) настолько возросли, что на нем вполне можно создавать очень сложные программы как локального характера, так и тиражируемые системы.

Описание некоторых приводимых в статье решений предполагает наличие специальной версии для разработчика Microsoft Access: для версии Office 97 - это Access Developer’s Toolkit (ADT), для более поздних версий - Office Developer’s Edition (ODE).

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

Разработка распространяемого приложения

Разработка базы данных

Тут необходимо решить вопрос с выбором хранилища данных и способом доступа к этим данным. Access предлагает достаточный выбор: Jet/DAO, ODBC, ADO. К сожалению, нет возможности останавливаться подробно на этом важном вопросе в данной статье. Стоит разве что отметить, что стратегия развития Microsoft Access идет по пути вытеснения собственного хранилища (MDB) серверными источниками данных (SQL-сервер).

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

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

Разработка концепции интерфейса пользователя

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

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

Разделение интерфейса и базы данных

Об этом говорится практически в любой книге или статье по программированию в Access для начинающих. Просто добавлю, что полное отделение интерфейса может вызвать некоторые затруднения при работе с MDB/MDE. Безусловно общие данные должны быть перенесены на сервер (файл или SQL). Но все-таки нецелесообразно держать временные таблицы (если таковые используются) в дополнительном локальном MDB-файле. Тем более что это, к сожалению, не приводит к стабилизации размера основного файла интерфейса (все равно требуется регулярное сжатие).

Групповая разработка

Access вполне подходит для разработки приложения несколькими программистами, несмотря на то что рабочий проект (MDB или ADP) представляет собой единый файл. Категорически нельзя использовать совместный доступ к рабочему файлу интерфейса – это приведет к повреждению самого проекта. Но Access содержит специальные методы сохранения и восстановления объектов программы в текстовом виде (Application.LoadFromText, Application.SaveAsText). К сожалению, по непонятным мне причинам разработчики не включили возможности сборки проекта из модулей в среду разработки. Но при наличии некоторого навыка вы можете написать собственную надстройку по выводу проекта в текстовый вид и последующему восстановлению (разработанная в нашей компании надстройка позволяет преобразовывать в текстовые файлы все возможные объекты Access: формы, модули, отчеты, запросы, таблицы с данными, ссылки, панели инструментов). Это нужно для поддержки популярных программ групповой разработки приложений (CVS, SourceSafe, TortoiseSVN). Включаемая в ODE-версию Access программа SourceSafe по идее должна была бы поддерживать такую операцию автоматически, но нам не удалось найти такую опцию (буду рад ошибиться, если она там все-таки есть).

Документация

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

Что может потребовать дополнительных комментариев и даже отдельной документации, так это структура базы данных. Существует множество систем для моделирования структур данных и бизнес-процессов (ErWin, Power Designer). Минимально необходимые действия по оформлению структуры данных можно проделать при помощи собственных диаграмм данных Access или SQL-сервера.

Специальные средства

Наследование интерфейсов

О невозможности «нормального» наследования в классах Visual Basic может поведать любой программист, воспитанный на классических объектно-ориентированных языках программирования. Не буду никого переубеждать – даже скорее соглашусь с этим утверждением. Судя по направлению развития средств разработки от Microsoft, в следующих версиях Access этот пробел все-таки будет устранен. Тем не менее, даже в текущей версии можно (и нужно) использовать возможности ООП VBA по максимуму. Постарайтесь понять возможности наследования интерфейсов. Эта особенность языка возможно и не добавит ожидаемой функциональности наследования, но сделает код программы более наглядным, понятным, простым для развития и переноса на другую платформу.

Шаблоны кода

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

Экземпляры форм

Access позволяет работать с несколькими экземплярами одной и той же формы или отчета. По непонятным мне причинам в документации и примерах Microsoft рекомендует использовать традиционный способ открытия форм (через команду DoCmd.OpenForm). По опыту работы мы не нашли каких-либо скрытых ошибок при использовании экземпляров форм, при том что это добавляет значительно больше возможностей по программированию интерфейса и делает его более современным и удобным конечному пользователю.

Временные таблицы и запросы

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

Обработка собственных событий

Ориентация на события является большим шагом вперед в развитии программных систем. Программы Access также можно заставить обрабатывать ваши собственные события, причем без привлечения функциональности сабклассинга и Windows API. События в этом случае представляют собой объект класса и обрабатываются специальными скрытыми формами (процессорами), загружаемыми при старте программы. Через события можно передавать результаты из модальных окон, контекстно обновлять списки на всех открытых рабочих формах, запускать серверные процедуры в асинхронном режиме и т.п. Таким образом, можно практически избавиться от использование глобальных переменных. Кроме того, VBA предоставляет специальную функциональность для взаимодействия классов через события (см. справку по WithEvents и RaiseEvent).

Условная компиляция

Это мощное средство, позволяющее тиражировать программные модули в различные проекты при незначительном изменении функциональности (см. справку по #If). Хотелось бы только обратить внимание, что условная компиляция имеет смысл только при добавлении условия непосредственно в свойства проекта VBA (меню Tools\<projectname> Properties). При использовании ключевого слова #Const большинство полезных свойств условной компиляции теряется, так как такая константа имеет область видимости только на уровне модуля.

Надстройки

Может оказаться полезным вынести некоторую функциональность приложения в отдельный файл надстройки. Access поддерживает три типа надстроек: отдельный файл, инсталлируемые надстройки (требующие USysRegTable) и COM-надстройки. Надстройка в виде отдельного файла должна быть установлена в тот же каталог, что и файл msaccess.exe. В этом случае не потребуется устанавливать связь с эти файлом на уровне коллекции References. Очень полезно при программировании надстроек использовать описание Friend для свойств и методов классов – в обычном проекте Access это описание не отличается от Public. Инсталлируемые и COM-надстройки в основном предназначаются для облегчения процесса разработки и могут быть бесполезны конечному пользователю программы (пользователь может вообще не иметь стандартной версии Access).

Сабклассинг

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

Обсудить на форуме...

читать далее >>