В этой главе внимание сконцентрировано на выборе инструментальных средств и языков разработки, с помощью которых осуществляется сопровождение данных в базе данных и выполняются запросы к ним. Конечно, это делается не в каждом проекте — иногда заранее обуславливается, какими продуктами необходимо пользоваться. Многие организации принимают те или иные средства разработки в качестве стандартных, чтобы обеспечить согласованность приложений и рационально использовать навыки, опыт и усилия разработчиков. В этой главе мы рассмотрим категории инструментальных средств, которыми вы можете пользоваться (средства разработки экранных форм, генераторы отчетов и т.д.), опишем, какими соображениями следует руководствоваться при их выборе, и затронем специфические вопросы, касающиеся разработки систем клиент/сервер.
Типы инструментальных средств
Для выполнения различных функций в большинстве приложений понадобится та или иная комбинация инструментальных средств. Продавец какой-нибудь фирмы, возможно, убедил ваше руководство в том, что в последней версии продукта этой фирмы можно эффективно создать абсолютно все, но, как правило, вам будет нужна комбинация инструментальных средств для управления следующими компонентами:
Формы
Экранные формы для ввода, сопровождения и запрашивания данных.
Отчеты
Печатные и, возможно, экранные отчеты.
Пакетные процессы
Процессы, поддерживающие механизмы подачи данных и обработку больших объемов данных.
Нерегламентированные запросы
Поддержка нерегламентированных запросов.
Средство интеграции
Средство, собирающее различные компоненты в одно цельное приложение.
Хотя проектировщик, вероятно, будет участвовать в выборе инструментальных средств, окончательное решение обычно принимает не он. Во многих случаях на это решение влияют внешние факторы и предпочтения. У многих фирм имеется список "стратегических" продуктов, которые используются в каждой разработке, если только нет хорошего обоснования для применения других средств. Предлагая альтернативные варианты, следует делать больший акцент на ожидаемом повышении производительности и экономии средств, а не на эстетической стороне разных продуктов.
У одного из авторов еще живо в памяти воспоминание о том, как он пытался уговорить клиента-консультанта написать всего один модуль (из почти 750) на Рго*С, а не на PL/SQL. Руководитель проекта настаивал на том, что поскольку PL/SQL является корпоративным стандартом, то следует использовать этот язык. В соответствующем разделе отчета консультанта было написано:
Я согласен с вашими разработчиками, что на
PL/SQL технически невозможно написать модуль, который удовлетворял бы поставленным требованиям к производительности. Кроме того, затраты на разработку варианта на PL/SQL примерно в десять раз больше, чем варианта на С.
Новый руководитель проекта больше года старался решить проблемы производительности средствами PL/SQL, пробуя вариант за вариантом, после чего наконец санкционировал написание этого модуля на Рго*С. Для создания и тестирования понадобилась неделя работы одного программиста, и проблемы производительности были решены.
У нас есть пословица:
Если инструментальное средство не делает то, что вы хотите, поменяйте то, что вы хотите.
Если инструментальное средство не делает то, что вам нужно, поменяйте инструментальное средство.
Какие критерии отбора важны?
Если выбор инструментальных средств не продиктован, то необходим приемлемый формальный метод принятия решения. Сначала вы должны решить, какие критерии являются наиболее важными. Вот некоторые из них:
• переносимость кода между аппаратными и программными платформами;
• возможность поддержки средств клиент/сервер, описанных в главе 11;
• степень "осведомленности " продукта о базе данных. Она отражает объем работы, необходимый для того, чтобы программы могли взаимодействовать с базой данных. У инструментальных средств, имеющих высокий уровень "осведомленности" о базе данных, стандартные возможности работы с БД уже встроены во все приложения;
• поддержка генерации кода из CASE-средства;
• совокупность навыков разработчиков либо наличие консультантов, знающих эти инструментальные средства;
• степень "современности" продукта и вероятность того, что он будет поддерживаться многие годы;
• сложность инструментального средства и возможная скорость написания и отладки программ;
• способность поддерживать многопользовательскую среду разработки и тестирования, в том числе степень интеграции со средствами контроля исходного кода;
• репутация и финансовая стабильность разработчика и (или) продавца инструментального средства, а также наличие справочной службы и средств поддержки.
Оценивая различные варианты, составьте свой список важных критериев (возможно, на основе нашего шаблона) и расставьте его элементы по приоритетам, указав возможности всех предлагаемых продуктов по каждому пункту. Если требования или приоритеты противоречат друг другу, можно выбрать несколько продуктов. Так, например, часто берут одно средство для написания основных, ориентированных на БД, приложений, а другое — как инструмент интеграции, создающий оболочку, в которой эти приложения работают. На фоне общих затрат стоимость собственно лицензий не кажется большой.
Если речь идет о выборе средств разработки и средств нерегламентированных запросов, то, вероятно, будет выгоднее получить копии предлагаемых продуктов для оценки. Процедуру оценки можно объединить с макетированием и разработать макеты в каждом из предлагаемых инструментальных средств или распределить макеты между данными продуктами. Очевидно, это повлияет на время макетирования. Большинство продавцов ПО бесплатно предоставляют копии своих программ для пробной эксплуатации, но при этом следует помнить, что пробные прогоны нужно выполнять объективно и непредвзято. Если тот или иной продавец не даст вам такую копию бесплатно, не беспокойтесь, вы увидите, что стоимость одной такой копии большинства ПО ничтожна по сравнению со стоимостью организации пробного прогона.
Инструментальные средства для систем клиент/сервер
Существует ряд специфических вопросов, которые необходимо исследовать при оценке инструментальных средств для среды клиент/сервер. Взаимодействие между клиентом и сервером осуществляется одним из трех способов:
• прямое SQL-соединение через SQL*Net;
• SQL-соединение через ODBC-драйвер;
• направление удаленных вызовов процедур на серверы приложений, выдающие все запросы к базе данных.
На практике в настоящий момент времени широко распространены только первые два способа. Третий начинает выглядеть как вариант для Web-приложений и для развертывания архитектуры сетевых вычислений Oracle (NCA). Без сомнения, в Oracle есть люди, считающие, что это одно и то же и что каждый Oracle-узел, развертывающий Web-приложения, автоматически принимает NCA.
Некоторые продукты, например Powerbuilder фирмы Powersoft, позволяют выбрать любой из двух вариантов SQL-соединений, поэтому важно знать о различиях между ними. Во-первых, для использования ODBC необходим ODBC-драйвер, хотя необходимые драйверы довольно часто продаются в комплекте с инструментальными средствами. При использовании SQL*Net можно свободно писать SQL-код, включающий Oracle-расширения стандарта ANSI. Если же применяется ODBC-драйвер, он может попытаться разобрать этот SQL-код и отклонить SQL, не соответствующий стандарту ANSI.
Это ограничение приводит к появлению проблем, когда мы пытаемся проектировать экранную форму, позволяющую администратору приложения сопровождать пользователей, поскольку такие команды, как ALTER USER и DROP USER в стандарте ANSI отсутствуют. Это ограничение касается почти всех DCL- и DDL-операций в Oracle7. Документ The Oracle7 Server SQL Reference Manual содержит перечень Oracle-расширений стандартного SQL, а руководство для версии 7.2 — список более чем 60 команд SQL, поддерживаемых Oracle7, но не входящих в стандартный SQL. Для тех, кто не знаком с ограниченной областью применения стандарта (стандартов) на SQL, сообщаем, что этот список включает команду CREATE SYNONYM.
В большинстве ODBC-драйверов это ограничение ANSI можно обойти, установив опцию, называемую режимом ретрансляции (pass through mode). Этот режим заставляет драйвер передавать SQL прямо на сервер, не интерпретируя его. Это позволяет использовать SQL, не соответствующий стандарту ANSI, но лишает нас одного из главных преимуществ ODBC, которое заключается в следующем. Если режим ретрансляции не применяется, то приложение можно сделать независимым от базы данных. Это значит, что теоретически оно должно работать с Oracle7, Sybase, SQL Server, Informix и т.д. Если это важно — например, в случае, когда создается продукт, который планируется продавать на более широком рынке, чем рынок серверов Oracle7, — то следует в качестве стандарта разработки применять ODBC без режима ретрансляции. Однако в этом случае вам пригодится лишь очень малая часть нашей книги (не считая раздела о псевдокоде).
Иногда режим ретрансляции включают из-за того, что предполагают, будто наличие промежуточного ПО (ODBC-драйвера, интерпретирующего SQL) влечет очень высокие затраты и сильно замедляет работу приложения. Однако это зависит от конкретного ODBC-драйвера. Ведь ODBC — это просто стандарт, и на рынке есть множество драйверов. Некоторые из них обеспечивают высокую скорость работы вне зависимости от режима. Опять-таки, ценным подспорьем здесь могут быть оценка по результатам макетирования и эталонные тесты драйверов. Следует помнить одно: если ODBC-драйвер интерпретирует и переписывает SQL, он может удалить встроенные комментарии, в том числе и те, которые являются подсказками оптимизатору Oracle7. Это серьезно ограничит возможность воздействия на сервер при оптимизации производительности некоторых SQL-запросов.
В заключение скажем, что в первом стандарте на ODBC (ODBC 1) программа может вызывать хранимую процедуру или функцию базы данных и передавать ей параметры. Однако такая процедура не может возвращать значения в вызывающую программу. Это существенно ограничивало возможности проектирования интерфейса клиент/сервер, так как хранимые процедуры обычно играют здесь важную роль. В стандарте ODBC 2.0 это упущение исправлено.
Если рассматривается возможность использования Microsoft Visual Basic или Visual C++ в качестве внешней системы, существует альтернатива ODBC (или встроенному SQL) — Oracle Objects for OLE (OO4O). По стилю программирования этот продукт очень похож на ODBC, но написан специально для сервера Oracle7 и, следовательно, оптимизирован под Oracle.
Некоторые средства разработки для клиентов имеют встроенную СУБД. Это может быть полезно для разработки на базе ПК, поскольку в противном случае нам потребуется доступ к серверу Oracle7 (или к Personal Oracle7, если на ПК достаточно оперативной памяти). Вот некоторые примеры:
• Blaze в Oracle Power Objects версии 1.x;
• Oracle Lite в Oracle Power Objects версии 2.x;
• Jet в Microsoft Visual Basic;
• Interbase в Borland Delphi;
• Watcom SQL в Powersoft Powerbuilder.
Эти СУБД не обладают всеми функциональными возможностями Oracle7. В частности, они не поддерживают ограничения целостности и компоненты кода, такие как триггеры и хранимые процедуры. Эти ограничения диктуют уровень, до которого может успешно продолжаться разработка в автономной конфигурации, что делает Personal Oracle7 гораздо более приемлемым вариантом. Недавно Oracle представила продукт Oracle Lite, который способен работать в одном мегабайте оперативной памяти, но это, опять-таки, весьма ограниченная СУБД, нацеленная, скорее, на рынок встроенных систем, нежели на рынок приложений.
Мы можем описать предыдущую категорию как клиентское инструментальное средство разработки со встроенной СУБД, которое может также обращаться к удаленной БД на сервере, обычно посредством ODBC. Есть еще один тип комбинации инструментального средства разработки с базой данных — эту категорию продуктов можно назвать клиентской СУБД со встроенными средствами разработки. Примеры средств этой категории — Microsoft Access и Borland Paradox.
При проектировании систем клиент/сервер с помощью таких средств следует помнить об одной ловушке. Мы можем (сознательно) решить использовать локальную базу данных для хранения определенных неизменчивых данных, например справочных. Присоединяя локальные таблицы к серверным таблицам, мы, по сути дела, оказываемся в "сумеречной зоне" распределенной базы данных. Мы хотим, чтобы серверная БД оставалась под нашим контролем, поскольку именно там расположена основная масса наших данных и средств обработки. Однако иногда клиентская база данных начинает борьбу за власть и пытается взять все в свои руки. Из серверной базы данных в клиентскую загружаются большие таблицы (часто целиком) для последующего соединения с локальной таблицей на клиенте (см. рис. 19.1). Очевидно, что такие стратегии катастрофически ухудшают производительность.
Рис. 19.1. Проблемы, возникающие при попытках диспетчера клиентской базы данных взять все под свой контроль
Некоторые клиентские средства разработки систем генерируют код, который не может использовать ни общедоступные, ни частные синонимы, определенные в базе данных. Некоторые средства могут работать только для пользователя, владеющего данной таблицей, поскольку они не поддерживают табличные ссылки, в которых в качестве префикса используется имя схемы (schema.table). Если в оцениваемом средстве разработки это имеет место, необходимо рассмотреть возможные последствия для безопасности — например, в случае, если всем нужно подключаться к базе данных под одним и тем же пользовательским идентификатором.
Проектирование для
World Wide Web
Многие новые приложения будут разрабатываться в расчете на развертывание через Web-броузеры. В организациях, где у будущих пользователей уже есть какой-нибудь Web-броузер, трудно увидеть причину, по которой новое приложение вдруг может захотеть пользоваться другим интерфейсным инструментом. Говоря так, мы не предлагаем открывать все новые приложения всему всемирному Web-сообществу. Мы просто отмечаем, что броузерная технология создает очень удобный способ развертывания нового приложения по интранет, а не по Интернет. Для того чтобы разделить эти сети, нужно либо вообще не подключать внутреннюю сеть к Интернет, либо поставить надежный брандмауэр.
Однако следует отметить, что если вы предполагаете двинуться поэтому пути, то мы настоятельно рекомендуем обратиться к трехуровневым архитектурам и удалить из кода пользовательского интерфейса все прямые ссылки на базу данных. Эти ссылки следует поместить на сервер (серверы) приложений. На рис. 19.2 мы показали только один сервер приложений и две базы данных, которые некоторые приложения могут сопровождать отдельно, а некоторые — вместе.
Знаете ли Вы, что диаграмма состояний, Statechart diagram - это методология объектно-ориентированного проектирования, предназначенная для представления жизненного цикла объектов в реальном или абстрактном мире.
