WEB vs GUI: точка зрения разработчика

Страница 2 из 2. Вернуться на первую страницу.

Работа с базами данных

Отдельно нужно сказать о различии интерфейсных метафор при работе с базами данных в случае GUI- и WEB-интерфейсов.

Как я уже писал когда-то в «Блеске и нищете клиент-серверных технологий» (ссылка), основная задача инструментария для разработки локальных (GUI) СУБДшных приложений — сделать вид, что никакого клиент-сервера у нас нет, и пользователь успешно работает со своей настольной СУБД. И на это ориентированы соответствующие интерфейсные метафоры.

В этом смысле веб-система требует существенно более честной реализации идеологии «клиент-сервер», поскольку требует минимизировать количество обращений к серверу. И метафоры «простыни» (grid-a) которую мы неограниченно листаем вверх-вниз, тут нет и быть не может.
Поэтому использование форм запроса для явной спецификации того, что мы хотим получить, и неявные запросы путем перехода по связямь получили существенно более широкое распространение, чем в GUI-приложениях. А обширная выдача в вебе всегда четко нарезана на страницы небольшого объема, с явно выраженной и достаточно «тяжелой» операцией листания. Зато хорошей практикой стала выдача информации о суммарном количестве записей в получившейся выборке…

И в общем, выяснилось, что от отсутствия пресловутой «простыни» и понятия «текущая позиция в таблице» никто особо не страдает. Так что я даже начал задумываться — а так ли она необходима даже в настольных приложениях?

Еще, как я писал выше, для web-систем неприемлем «пессимистический» подход, основанный на блокировках записей, взятых на редактирование. Могут использоваться только «оптимистические» стратегии, основанные на проверке многопользовательских изменений при попытке записи данных.

Причем этот момент требует особого внимания, так как существование кнопки «Назад», возможность остановки запроса на запись и попытки повторного его исполнения тем же пользователем гораздо более вероятны, чем собственно многопользовательские коллизии.

Управление контекстами

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

В классическом GUI-приложении, когда каждый пользователь обслуживается отдельной копией задачи, контекст «замурован» в набор данных и состояние исполнения (cтек) задачи.

В случае веб-приложения все пользователи обслуживаются, как правило, одной задачей (веб-сервером и сервером приложений). И этот самый сервер, получив «пинок» от браузера, должен понять, что делать и какой HTML сгенерировать и отдать этому браузеру.

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

Эту область данных мы будем называть контекстом, а период его существования — от момента входа пользователя в систему до уничтожения контекста — сессией. Контекст идентифицируется либо по имени пользователя, пришедшему в составе запроса, либо по специальному идентификатору сессии, который «гоняется» между браузером и сервером, либо в параметрах URL (вы наверняка видели при работе с разными веб-сайтами в URL что-то типа session_id=ХХХХ), либо в куке.

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

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

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

Существующие серверы веб-приложений, поддерживающие самые популярные технологии (PHP, ASP, JSP), поддерживают понятие сессий, полностью принимая на себя управление (создание, отслеживание, удаление) контекстами.

Но в явном виде понятие сессии нужно не всегда — часто необходимый контекст вполне можно держать в куках и/или базе данных. Скажем, в системе разработки Communiware сессии в явном виде вообще нет.

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

Промежуточные варианты

Описанные выше фундаментальные различия породили много попыток решить их и с помощью каких-то инструментальных средств программирования. Попытки эти шли по двум направлениям, решающим, вообще говоря, разные задачи.

1 Замена HTМL-интерфейсов специализированными агентами (ActiveX, Java-апплеты, в какой-то степени Flash и др.).

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

2 Разработка библиотек и серверов приложений, обеспечивающих «трансляцию» локальных интерфейсов через веб — как я их назвал в свое время, «веб — удлинители». Одной из таких систем был Байконур, с которым мне пришлось плотно поработать в конце девяностых.

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

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

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

Наша сила — обратная сторона нашей слабости

С моей точки зрения, основным преимуществом веб-интерфейсов является:

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

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

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

Даже возможность перехода от упоминания объекта в любом контексте к описанию объекта, тривиальная для любого веб-приложения (ссылка), проблематична для широкомасштабной реализации в GUI. Не говоря уж о возможности встраивания форм редактирования объектов, которые генерируются в HTML так же легко, как и просто текст.

Далее — бедность изобразительных средств HTML обеспечивает высокий уровень стандартизации приложений (пользователь получает единообразный интерфейс), и существенно ограничивает возможность авторских изысков, которые чаще идут во вред, чем во благо.

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