Полезная информация

РАБОТАЕМ С ДАННЫМИ

КОМПЬЮТЕРНАЯ ГАЗЕТА

Формообразование. Уверенная поступь

Я занимаюсь профессиональной разработкой Систем Управления Базами Данных (СУБД) уже несколько лет, поэтому большой интерес вызвала у меня серия статей А. Запольскиса об основах построения форм, в частности в среде СУБД Аccess. Нисколько не умаляя профессиональных навыков автора и не подвергая сомнению подходов, предлагаемых Александром, хочу дополнить тему своими взглядами на проектирование интерфейса СУБД.

(c) Компьютерная газета

Прежде всего замечу, что мой любимый инструмент - это СУБД Visual Fox Pro 5.0. Я специально делаю эту оговорку, так как возможности Access и Visual FoxPro существенно отличаются. Понятно, что многие мои примеры основаны на возможностях, предоставляемых FoxPro.

В своей статье Александр неоднократно подчеркивал трудоемкость программирования контроля ввода и "отлова" недопустимых действий пользователя. К счастью, сейчас все больше распространение получает более совершенный метод проектирования СУБД, связанный прежде всего с понятиями "хранимые правила и процедуры". База данных в этом случае представляется не просто в виде набора файлов с пусть и четко структурированными, но все же мало защищенными "от дурака" данными, а в виде объекта-контейнера, в состав которого входит уже минимум два компонента - непосредственно данные и правила их обработки (я написал "минимум", поскольку в реальности в состав БД в Visual FoxPro можно включить еще несколько компонентов: локальные представления, удаленные представления, триггеры, хранимые процедуры и другие полезные вещи).

Если мы упрощенно рассмотрим это на практике, то картина будет следующей. Воспользуемся теми же данными, с которыми работал Александр. У нас есть таблица "Литература", в которой есть два поля: "Название" и "Автор".

Представим, что в эту таблицу мы вводим данные с помощью формы. Естественно, форма спроектирована должным образом - записи с пустым значением полей "Название" и "Автор" программа будет отвергать и попросит в этом случае заполнить необходимые поля. Для достижения этого эффекта необходимо запрограммировать контроль на ввод пустых значений. В данном случае это сделать легко, вставив несколько строк кода для каждого поля на форме (используя функцию типа Empty()), поскольку мы имеем дело только с двумя полями. А если мы работаем в обход формы? Давайте представим, что кто-то (случайно) открыл таблицу с вашими драгоценными данными и очистил значение "Автор" одной из записей, скажем, при помощи команды табличного просмотра-редактирования таблиц BROWSE (в FoxPro). Реакции на надругательство не будет никакой. И это самый безобидный случай. А если очищенное поле являлось полем-связкой с другой таблицей? Это уже близко к катастрофе.

Встроенные возможности аппарата БД Visual Fox Pro позволяют вам пресечь все попытки в изменении критических данных благодаря механизму встроенных правил. Обратимся к таблице "Литература": при создании ее традиционным методом мы лишь описываем структуру таблицы (см. табл.1).

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

В нашем случае это будет выглядеть так (см. табл.2).

Введенные правила будут записаны в самой структуре БД один раз, и их более незачем дублировать в формах. Что мы получим в результате? Каким бы способом доступа к данным ни воспользовался пользователь (форма, SQL команда, редактирование "в лоб"), система активизирует правила для каждого поля, предусмотренные на этапе проектирования структуры таблицы, и ни за что не примет некорректных данных, выдав при этом предусмотренное сообщение об ошибке. Кроме очевидного достижения корректности ввода, мы сразу добиваемся и роста производительности разработки: как только мы связываем поле данных таблицы, для которого установлены правила проверки с элементом управления на форме, эти правила будут сразу же срабатывать при манипуляции над данными этого элемента управления. Без утомительного прописывания (порой одного и того же) программного кода. То есть - в нашем случае для построения формы ввода в таблицу "Литература" достаточно перетащить на чистую форму соответствующие поля из таблицы, добавить заголовок и кнопку сохранения. Работа над формой закончена.

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

Взгляните - здесь и поля ввода, и список, и чекбоксы и много еще чего, общим количеством элементов ввода - 15. Тем не менее, несмотря на большое количество элементов управления, почти за каждым из них стоит своя соответствующая проверка. Причем без единой строки кода в самой форме! Работа по программированию была сделана на этапе проектирования БД. Удобно? Я думаю, ответ очевиден.

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

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

1. Поскольку все элементы стандартны, то пользователю не нужно дополнительное время на освоение взаимодействия с системой. Имея накопленный опыт работы с другими приложениями, пользователь пытается применить этот опыт и при "общении" с новой системой. Хорошо, если новая система это позволяет и достаточно дружественна. В качестве игнорирования этого факта и мягкого издевательства над пользователем могу привести, на мой взгляд, довольно яркий пример, боюсь, правда, что вызову шквал недовольных окриков. Кто пользуется программой Adobe Photoshop, наверняка прикрутил себе и фильтры от Kai. При несомненной ценности продукта и оригинального эстетического решения интерфейса требуется чудовищно долгое время на его освоение. Попросту говоря, долго тыкаешься в эти миленькие кнопки-шарики, пока выяснишь, что же они и как делают, - в конце концов в сердцах жмешь на F1 и... До интуитивно-понятного такому интерфейсу еще далеко.

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

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

Все выглядит замечательно, не правда ли? Но...

Представьте, что вдруг все люди будут ходить в одинаковой одежде. Пусть от самого крутого модельера и скроенной по самой последней моде. Города превратятся в угрюмые бетонные джунгли с одинаковыми жителями, упакованными в стандартную, трижды сертифицированную и признанную лучшей одежду. Жуть? Если спроецировать это на программирование... ну, представьте себе Quake, сработанный в стиле Microsoft Office...

Все-таки как ни крути, а человеческая натура такова, что требует проявления индивидуальности. Тем более, что творческие и гибкие люди (не только на Западе) уже доказали жизнеспособность другого тезиса: "При одинаковой функциональной насыщенности нескольких программ, имеющихся на рынке, наиболее конкурентноспособной будет программа с наиболее эффектным интерфейсом". Особенно это касается развлекательных вещей типа мультимедийных энциклопедий (у которых, кстати, ядро построено зачастую на архитектуре СУБД) и домашних приложений. В самом деле, ну кому захочется просматривать каталог видеозаписей при помощи самой стандартной и привычно выглядящей командной строки?

Исходя из приведенных выше соображений я конструирую экранные формы в зависимости от их назначения. При разработке приложений для промышленного использования я избегаю ярких решений и замысловатых интерфейсов, а пользуюсь стандартными элементами. Быстро и производительно. Если работа идет над программой для "домашнего" применения - я большее значение придаю внешнему виду форм (не в ущерб функциональности, разумеется, см. рис.2).

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

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

Таблица 1. Структура таблицы "Литература"
Название поля Тип данных Размер
Название книги Символьный 40
Автор книги Символьный 30

Таблица 2. Структура таблицы "Литература" с использованием правил проверки на уровне полей

Название поля Тип данных Размер Правило проверки Сообщение об ошибке
Название книги Символьный 40 .NOT.Empty(Название книги) "Поле 'Название книги' должно быть заполнено"
Автор книги Символьный 30 .NOT.Empty(Автор книги) "Поле `Автор книги' должно быть заполнено"

Виктор Гмыря