    21 ГЛАВА 

    Бизнес-правила в приложениях 

    В этой главе рассматриваются те случаи, когда реализацию бизнес-правил 
лучше вынести в клиентную часть системы клиент/сервер. В предыдущей главе 
утверждалось, что желательно реализовать бизнес-правила на сервере. Однако в 
реальных приложениях вам неизбежно придется использовать для этих целей не 
только сервер, но и приложение или (и) вспомогательные программы. Я тешу себя 
надеждой, что в один прекрасный день серверы баз данных, вспомогательные 
системы и средства разработки программного обеспечения достигнут такого уровня 
согласованности, что разработчикам больше не придется думать о том, где 
реализовывать бизнес-правила, — вместо этого они смогут сосредоточиться на 
том, как это сделать. 
    Опытные разработчики программного обеспечения часто склонны помещать 
значительную часть логики бизнес-правил системы клиент/сервер непосредственно 
в само приложение. Мир средств разработки для них более привычен, да и СУБД по 
историческим причинам всегда испытывали недостаток в удобных и, вместе с тем, 
мощных средствах реализации бизнес-правил, столь необходимых для создания 
безупречных приложений. 
    Несмотря на это, как я уже говорил, массовое перемещение бизнес-правил в 
приложения — не выход. Разработчики должны заставить производителей СУБД и 
вспомогательного программного обеспечения разработать удобные интерфейсы для 
бизнес-правил, отвечающие требованиям профессиональных приложений. Просто 
сдаться и принимать решения на основе худшей технологии — не выход из 
положения. Лучше заставить производителей пойти навстречу потребностям 
заказчиков и обеспечить такую поддержку бизнес-правил, которую смогут 
использовать настоящие приложения. Пока это не будет сделано, системы 
клиент/сервер будут почти так же незащищены от нарушения бизнес-правил, как и 
локальные СУБД. 
    К чести производителей СУБД и вспомогательного программного обеспечения, 
ими сделаны огромные шаги в развитии стратегии бизнес-правил. В прошлом 
механизмы реализации бизнес-правил на сервере были "вещью в себе" — очень 
часто разработчики сталкивались с трудностями в организации слаженной 
совместной работы объектов баз данных и приложений. Например, если в Sybase 
объект используемого по умолчанию значения применялся при вставке новой 
строки, то приложение при добавлении строки к таблице никак не могло узнать об 
этом, чтобы вывести на экран соответствующее значение. Приходилось либо 
игнорировать бизнес-правила сервера и лишний раз определять их в приложении, 
либо отмахнуться от необходимости синхронизировать обновление информации на 
экране с изменениями в базе данных. Оба решения не очень-то привлекательны и, 
как однажды заметил Джерри Гарсия (Jerry Garcia): "Выбирая меньшее из двух 
зол, вы все равно выбираете зло". 
    Сегодня производители СУБД и вспомогательных программ все больше 
прислушиваются к мнению разработчиков. Создавать качественные бизнес-правила 
стало легче, чем когда-либо раньше. С другой стороны, средства разработки, 
такие как Delphi, также становятся все более "сообразительными" по отношению к 
своим "коллегам" на другом конце провода — базам данных и вспомогательным 
программам. В результате серверные продукты и средства разработки 
объединенными усилиями полнее удовлетворяют нужды пользователей. От этого мы с 
вами только выигрываем. Реализовать продуманную стратегию бизнес-правил 
становится все легче по мере того, как платформы СУБД, вспомогательные системы 
и средства разработки учатся работать вместе. 
    Но что бы ни ждало нас в будущем, а работать нужно сейчас. В сложившейся 
ситуации вам, вероятно, придется реализовать часть бизнес-правил, необходимых 
для работы системы клиент/сервер, в самом приложении. Как уже говорилось в 
предыдущей главе, я предпочитаю следующий подход: сначала разместить на 
сервере максимально возможную часть бизнес-правил, затем с оставшейся частью 
проделать то же самое для вспомогательного программного обеспечения, а потом, 
если необходимо, — для приложения. Не важно, имеете ли вы дело с 

    424     IV. Темы повышенной сложности 


таблицами Paradox или с полноценной системой клиент/сервер. Только то, что 
невозможно сделать на сервере, реализуется с помощью вспомогательного 
программного обеспечения и приложения. 
    В этой главе рассматривается реализация бизнес-правил в приложении. Вы 
познакомитесь с различными средствами, используемыми для выработки эффективной 
стратегии реализации бизнес-правил на уровне приложения. Кроме того, вы 
узнаете о четырех основных уровнях реализации бизнес-правил в приложениях 
Delphi: уровне типа данных, уровне компонентов, уровне TField и уровне 
TDataSet. Я подробно остановлюсь на каждом из них, что поможет вам 
использовать их впоследствии в собственных приложениях. 

    Типы бизнес-правил 

    Бизнес-правила бывают двух типов: простые и сложные. Простые правила 
обеспечивают достоверность простых объектов. Они, например, требуют, чтобы 
числовые данные попадали в числовые поля, столбцы дат содержали допустимые 
даты и т.п. Применение простых правил одинаково во всех приложениях и базах данных. 
    Сложные правила управляют более тонкими аспектами доступа к базам данных. 
Они обеспечивают корректность связей. Чаще всего эти правила специфичны для 
каждой базы данных или даже таблицы. 
    В этой книге понятие бизнес-правила используется в широком смысле этого 
слова. Сюда входят и простые, и сложные правила. Под "зонтиком" бизнес-правил 
прячется все — от простой проверки данных до сложных зависимостей. Хотя методы 
проверки данных можно рассмотреть отдельно, вряд ли это было бы правильным. 
Методы реализации простых правил ничем не отличаются от методов реализации 
сложных. Поэтому логично рассмотреть создание эффективных бизнес-правил 
вообще. Независимо от того, являются правила простыми или сложными, к ним 
нужно подходить с одинаковым вниманием. 
    Delphi предлагает много способов создания простых бизнес-правил, не 
требующих программирования, а также достаточный набор средств для 
конструирования сложных правил при минимальном использовании программного 
кода. В этой главе рассматриваются оба типа правил с точки зрения приложения. 
    Два правила создания бизнес-правил 
    Первый уровень реализации бизнес-правил в приложении — уровень типов 
данных. Есть два основных правила, которые лишний раз показывают важность 
правильного выбора типов данных. Если всегда следовать этим фундаментальным 
правилам, то многие проблемы, с которыми обычно сталкиваются разработчики, 
можно решить еще до их возникновения. 

    Правило номер один 

    Первое правило создания бизнес-правил на уровне приложения гласит: Сразу 
выбирайте подходящие типы данных. 
    В библиотеке VCL Delphi имеется большое количество встроенных простых 
ограничений, основанных на типе данных столбца. Например, компоненты, 
предназначенные для работы с данными, не допустят появления неправильной даты 
в столбце дат, символов алфавита в числовом поле или неправильных величин в 
поле типа Boolean. Для ввода этих ограничений не нужно ничего программировать; 
Delphi применяет их автоматически. Главное — с самого начала использовать 
соответствующие типы данных. 
    Разработчики-ветераны часто увлекаются строковыми типами данных. Мне 
приходилось видеть столбцы дат, определенных как строки. Встречались также 
строковые поля, используемые для хранения чисел. Если в столбце будут 
храниться только даты, определите это через соответствующий тип данных. Если 
столбец предназначен для чисел, присвойте его данным числовой тип — хранить 
числа как последовательность символов бессмысленно. 
    Другим примером ситуации, когда правильное определение типа данных 
является обязательным условием реализации бизнес-правил, является наличие 
столбцов, содержащих числовые последовательности. Хотя систему 
последовательной нумерации можно смоделировать, используя код Object Pascal, 
лучше всего использовать специально созданные для этих целей типы данных. СУБД 
Sybase SQL Server и Microsof SQL Server, например, поддерживают использование 
столбцов последовательностей (identity columns) — особых столбцов, содержимое 
которых автоматически увеличивается сервером на единицу. Используя типы данных 
с автоинкрементом, вы избавитесь от необходимости создавать последовательности 
вручную и обеспечите выполнение бизнес-правила типа "столбец Y таблицы X 
содержит последовательность" без всяких усилий со стороны программиста. 

    Глава 21. Бизнес-правила в приложениях	425 

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

    Два правила создания бизнес-правил 

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

    Правило номер один 

    Первое правило создания бизнес-правил на уровне приложения гласит: Сразу 
выбирайте подходящие типы данных. 
    В библиотеке VCL Delphi имеется большое количество встроенных простых 
ограничений, основанных на типе данных столбца. Например, компоненты, 
предназначенные для работы с данными, не допустят появления неправильной даты 
в столбце дат, символов алфавита в числовом поле или неправильных величин в 
поле типа Boolean. Для ввода этих ограничений не нужно ничего программировать; 
Delphi применяет их автоматически. Главное — с самого начала использовать 
соответствующие типы данных. 
    Разработчики-ветераны часто увлекаются строковыми типами данных. Мне 
приходилось видеть столбцы дат, определенных как строки. Встречались также 
строковые поля, используемые для хранения чисел. Если в столбце будут 
храниться только даты, определите это через соответствующий тип данных. Если 
столбец предназначен для чисел, присвойте его данным числовой тип — хранить 
числа как последовательность символов бессмысленно. 
    Другим примером ситуации, когда правильное определение типа данных 
является обязательным условием реализации бизнес-правил, является наличие 
столбцов, содержащих числовые последовательности. Хотя систему 
последовательной нумерации можно смоделировать, используя код Object Pascal, 
лучше всего использовать специально созданные для этих целей типы данных. СУБД 
Sybase SQL Server и Microsof SQL Server, например, поддерживают использование 
столбцов последовательностей (identity columns) — особых столбцов, содержимое 
которых автоматически увеличивается сервером на единицу. Используя типы данных 
с автоинкрементом, вы избавитесь от необходимости создавать последовательности 
вручную и обеспечите выполнение бизнес-правила типа "столбец Y таблицы X 
содержит последовательность" без всяких усилий со стороны программиста. 

    Глава 21. Бизнес-правила в приложениях	425 

    Правило номер два 

    Второе правило реализации бизнес-правил в приложениях гласит: 
    Используйте компоненты Delphi, наиболее подходящие для данных выбранного типа. 
    Самой распространенной ошибкой разработчиков в этом смысле является 
злоупотребление компонентами ввода текста. Такие компоненты, как DBEdit, TEdit 
и TMaskEdit, позволяют вводить данные, не соответствующие типам полей, в 
которые они вводятся. Обычно этого можно избежать путем использования 
подходящих компонентов. 
    Например, не стоит применять DBEdit для поля типа Boolean. В этом поле 
допускаются лишь два значения — True и False. Поэтому лучше использовать 
флажки, переключатели и раскрывающиеся списки. Не применяйте DBEdit и в том 
случае, когда поле постоянно используется только для чтения. Здесь 
предпочтительнее DBText. Это позволит сэкономить системные ресурсы и избавит 
от необходимости устанавливать свойство Readonly компонента. DBEdit не 
подходит также и в том случае, когда в числовом^ столбце допустим лишь 
ограниченный набор значений. В такой ситуации предпочтительнее воспользоваться 
компонентом DBRadioGroup. В табл. 21.1. устанавливается соответствие между 
компонентами и основными типами данных. 

    Таблица 21.1. Типы данных в столбцах и соответствующие им компоненты VCL 

    Тип данных      				Компоненты 

    Булев     	    				DBCheckBox,   DBRadioGroup,   DBComboBox,   DBListBox
    Дата     	    				DBEdit,   Calendar,   SpinEdit,   DataTimePicker
    Числовой (широкий диапазон значений)  DBEdit,   SpinEdit
    Числовой (ограниченное число значений)DBRadioGroup
    Строка (широкий диапазон значений) 	DBEdit
    Строка (ограниченное число значений) 	DBComboBox,   DBListBox

    Чтобы изменить тип элемента управления, представляющего то или иное поле, 
нужно отредактировать свойство TControldass в Database Explorer. Затем можно 
создавать необходимые компоненты путем пе-оетаскивания на форму компонентов 
TField из редактора полей. 
    Основная идея заключается в том, чтобы использовать компоненты, которые по 
своей природе обеспечивают правильность вводимых данных, чтобы не прибегать к 
специальной дополнительной проверке. 

    Компоненты 

    Следующим уровнем реализации бизнес-правил в приложениях является уровень 
компонентов (custom component layer). Архитектура Delphi, основанная на 
компонентах, предлагает разработчику большое количество качественных средств и 
богатых библиотек. Она позволяет встраивать бизнес-правила непосредственно в 
компоненты. Обычно для этого создаются новые компоненты-наследники класса 
DataSet, в которые затем встраивается логика бизнес-правил. 
    Как правило, с помощью таких средств можно определить все — от маски ввода 
для определенного поля до сложных зависимостей между таблицами. Данный принцип 
позволяет очень эффективно реализовать бизнес-правила, особенно в Delphi 1.0. 
    Недостатком этого подхода является возможность игнорирования бизнес-правил 
приложениями Delphi, поскольку никто не может заставить разработчиков 
использовать компоненты. Более того, подход с использованием компонентов 
характерен только для Delphi, и приложения, созданные с помощью других средств 
(за исключением Borland C++ Builder), не смогут воспользоваться логикой, 
заложенной в объектах класса TDataSet. 
    Для этого типа средств можно дать тот же совет, что и по поводу реализации 
бизнес-правил в приложениях вообще: даже если вы решили воспользоваться одним 
из них, по-прежнему постарайтесь реализовать максимум бизнес-правил в 
серверной части системы, а компоненты использовать лишь как средство 
расширения ее возможностей системы. 

    426 IV. Темы повышенной сложности 

    Свойства TFieid и бизнес-правила 

    Третий уровень реализации бизнес-правил в приложении — уровень свойств 
компонентов TFieid. Хотя обычно под бизнес-правилами подразумевают более 
сложные объекты, чем обычные поля ввода или метки, многие свойства компонентов 
класса TFieid так или иначе связаны с реализацией ряда бизнес-правил. Такие, 
например, свойства, как маска редактирования TFieid, требуют от данных, 
попадающих в столбец, соответствия особому формату. Это — пример простого 
бизнес-правила. Но на основе таких простых правил строятся более сложные 
структуры, такие как правила, обеспечивающие правильность связей между 
таблицами или определяющие используемые по умолчанию значения столбцов. 
Успешная реализация бизнес-правил требует внимательного отношения к их элементам. 
    Существуют два способа реализации простых бизнес-правил с помощью 
установки свойств компонента TFieid. Во-первых, можно использовать словарь 
данных Delphi и определить необходимые свойства TFieid через наборы атрибутов. 
Во-вторых, можно установить эти свойства непосредственно в 
компонен-"rax~DataSet приложения. Хотя оба пути ведут к одному результату — 
если определить ;roitTField параметры атрибутов (Attribute Set), то они станут 
частью компонентов TFieid приложения — все же стоит отдать предпочтение 
словарю данных (Data Dictionary). Определение свойств TFieid с помощью Data 
Dictionary более гибко и доступно, чем с использованием редактора полей 
DataSet. To, что невозможно или не имеет смысла определять через словарь, 
можно определить непосредственно через компоненты DataSet. В этой главе мы 
рассмотрим оба метода и отметим преимущества каждого из них. 

    Импортирование информации словаря 

    Описание данных можно импортировать в словарь данных Delphi из самой базы 
данных. Ограничения, используемые по умолчанию значения, типы данных и другая 
необходимая информация, хранящаяся на сервере, может быть целиком скопирована 
в словарь. Это дает возможность избежать дублирования серверных ограничений в 
словаре и помогает синхронизировать бизнес-правила сервера и приложения. Для 
импортирования информации с сервера в словарь данных нужно сделать следующее. 
    1.    Щелкните на вкладке Dictionary окна Database Explorer и раскройте 
список Databases. 
    2.    Выберите базу данных для импортирования информации в словарь данных. 
Эту информацию можно сохранить в новой базе данных словаря, открываемой по 
команде Dictionary* New, или в уже существующей, например в DBDEMOS, которая 
входит в комплект поставки Delphi. 
    3.    Из меню Dictionary выберите команду Import from Database. 
    4.    В открывшемся диалоговом окне Import Database выберите 
соответствующий вашей базе данных псевдоним BDE и щелкните на кнопке ОК. 
    При импортировании базы данных в словарь переносятся ограничения и другая 
информация уровня полей базы данных. Импортируются также домены с 
соответствующими ограничениями в виде наборов атрибутов. Этот процесс 
позволяет использовать импортированную информацию (с любыми внесенными 
изменениями) в приложениях Delphi. Таким образом, если импортировать из базы 
данных столбец, для которого определено ограничение CHECK, то это ограничение 
появится также и в приложениях Delphi, содержащих ссылку на данный столбец. 
Вместо того, чтобы обрабатывать ситуации, когда ограничение сервера 
отбрасывает недопустимые данные, приложение просто не позволит таким данным 
попасть на сервер. 

    Создание собственного набора атрибутов 

    Вместо импортирования наборов атрибутов из баз данных, можно создавать 
собственные наборы и связывать их с столбцами таблицы. Для создания и 
использования такого набора атрибутов нужно сделать следующее. 
    1.    На вкладке Dictionary щелкните правой кнопкой мыши на элементе 
Attribute Sets и в появившемся контекстном меню выберите команду New. 
    2.	Введите имя нового набора атрибутов. 
    3.	Установите необходимые свойства компонента TFieid. 
    4.	Чтобы сохранить эти свойства, щелкните на кнопке Apply панели 
инструментов Database Explorer. 

    Глава 21. Бизнес-правила в приложениях	427 

    5.    На вкладке Dictionary раскройте список Database и щелкните на 
столбце таблицы, с которой хотите связать новый набор атрибутов. 
    6.    На вкладке Definition раскройте список Attribute Set и выберите из 
него ваш набор атрибутов. 
    7.   Сохраните изменения, щелкнув на кнопке Apply панели инструментов 
Database Explorer. 
    Используя наборы атрибутов, можно установить различные атрибуты TField. 
Словарь данных Delphi предлагает исчерпывающий набор средств для реализации 
бизнес-правил через свойства TField. Преимущество определения правил в словаре 
данных по сравнению с компонентами семейства DataSet состоит в возможности 
использования бизнес-правил другими приложениями Delphi, ссылающимися на 
данную таблицу. Примерно тот же эффект получается при встраивании 
бизнес-правил некоторыми производителями средств разработки в компоненты, но 
без недостатковл связанных с использованием программного кода независимых разработчиков. 

    Определение бизнес-правил с помощью TField 

    Определить атрибуты TField можно не только с помощью словаря данных 
Delphi, но и непосредственно через сами компоненты TField. Если в меню 
редактора полей компонента семейства DataSet выбрать команду Add fields, то 
Delphi добавит компоненты TField на форму. При создании компонентов TField 
таким способом все атрибуты, определенные в словаре данных, отображаются в 
окне Object Inspector. 
    Чтобы создать бизнес-правило на основе TField, нужно сделать следующее. 
    1.   Дважды щелкните на компоненте семейства DataSet (TTable, TQuery или 
TStoredProc), чтобы перейти в окно редактора полей. 
    2.   Для создания компонентов типа TField нажмите комбинацию клавиш <Ctrl+A>. 
    3.   Для просмотра или изменения свойств поля в окне Object Inspector 
достаточно щелкнуть на этом поле. Required 
    Одним из основных свойств TField, значение которого задается в окне Object 
Inspector, является свойство Required. Оно определяет, должно ли поле 
содержать данные. Необходимость изменения стандартного значения этого свойства 
может возникнуть, например, в случае, когда данные для ключевого или другого 
столбца типа NOT NULL предоставляются сервером. Так как столбец обязателен для 
сервера, Delphi предполагает, что он обязателен и для приложения. Таким 
образом, по умолчанию свойство Required принимает значение True. Если же поле 
заполняется сервером, это условие не является необходимым. Более того, оно 
нарушает нормальную работу приложения. Изменение значения Required на False 
возлагает на сервер лишь обязанность следить за тем, чтобы величина принимала 
хоть какое-то значение. Но это он и так должен делать. 

    Вычисляемые поля 

    Вычисляемые поля используются для выполнения различных задач — от 
получения простых значений до проведения сложных вычислений с использованием 
других полей таблицы. В Delphi механизм вычисляемых полей позволяет 
производить математические операции, поиск в таблице, проверку правильности 
данных и т.п. Вычисляемые поля особенно удобны для отображения временных 
данных, которые используются только для просмотра каких-либо результатов. 
    Чтобы определить вычисляемое поле, нужно решить две основные задачи. 
    1.   Определить поле в редакторе полей соответствующего набора данных. 
    2.   Определить значение поля с помощью обработчика события OnCalcFields 
этого компонента семейства DataSet. 
    Для определения поля необходимо сделать следующее. 
    1.   Откройте редактор полей, дважды щелкнув на компоненте DataSet. 
    2.    Щелкните правой кнопкой мыши на списке полей и из появившегося 
контекстного меню выберите команду New field. 
    3.    В диалоговом окне New Field введите имя нового вычисляемого поля, 
выберите для него тип данных и установите режим Calculated в группе Field type. 
    1 

    428 IV. Темы повышенной сложности 

    4.   Завершите определение поля, щелкнув на кнопке ОК. 
    5.   Возвратившись в редактор полей, вы увидите в окне Object Inspector 
список свойств нового поля. Обратите внимание, что свойство Calculated имеет 
значение True. 
    6.   Теперь, когда поле определено, присвойте ему значение с помощью 
обработчика события OnCalcFields. Например: 

    taORDERSOrderDateTime.Value   := Now; 

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

    OnValidate 

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

    OnExit 

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

    Наборы данных и бизнес-правила 

    Следующим уровнем реализации бизнес-правил является уровень DataSet. Есть 
три события класса компонентов семейства DataSet (представителями которого 
являются компоненты Table, Query и StoredProc), заслуживающие отдельного 
рассмотрения. Этособытия OnNewRecord, BeforeDelete и BeforePost. Если провести 
аналогию с таблицами баз данных, то они приблизительно соответствуют триггерам 
INSERT, DELETE и UPDATE. 

    OnNewRecord 

    Событие OnNewRecord происходит всякий раз при появлении в таблице новой 
записи. Обработчик данного события можно использовать для присвоения значений 
столбцам таблицы. Приведенный ниже программный фрагмент определяет 
используемые по умолчанию значения столбцов PetDeposit и LawnService 
Таблицы LEASE. 

    procedure TForml.taLEASENewRecord(DataSet: TDataSet); begin 
    taLEASEPetDeposit.Value:=0; 
    taLEASELawnService.Value:=True; end; 

    Глава 21. Бизнес-правила в приложениях	429 

    BeforeDelete 

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

    taLEASE.IndexName:='Property_Number'; 
    If  taLEASE.FindKeyf[taPROPERTYProperty_Number.Aslnteger])   then 
    raise  EDatabaseError.Create('Property_Number   is   in  use   -   delete  
 failed1); 

    Этот фрагмент защищает от удаления строк таблицы PROPERTY, на которые 
ссылаются строки таблицы LEASE. 

    BeforePost 

    Событие BeforePost предшествует сохранению строки данных в таблице. Его 
можно использовать для проверки данных в новой строке или изменений в уже 
существующей. С помощью генерации исключительной ситуации в обработчике этого 
события можно остановить процесс сохранения неправильных данных. Ниже приведен 
программный фрагмент, обеспечивающий, чтобы дата LeaseEndDate хронологически 
следовала за датой LeaseBeginDate. 

    procedure  TForml.taLEASEBeforePost (DataSet:   TDataSet); begin 
    If   (taLEASELeaseBeginDate.AsDateTime   >   
taLEASELeaseEndDate.AsDateTime)   then 
    raise  EDatabaseError.Create('Lease  ending data must  come  after  its  
beginning  date'); end; 

    Существуют и другие особые события DataSet, которые можно использовать для 
реализации бизнес-правил в приложениях. Список таких событий приводится в 
табл. 21.2. 

    Таблица 21.2. Методы компонентов семейства DataSet, пригодные для 
реализации бизнес-правил в приложениях 

    Событие      	Когда происходит 

    AfterCancel	После отмены внесенных изменений 
    Afterdose	После закрытия набора данных 
    AfterDelete	После удаления данных 
    AfterEdit	После редактирования данных 
    Afterlnsert	После вставки или добавления строки 
    AfterOpen	После открытия набора данных 
    AfterPost	После сохранения данных 
    BeforeCancel	Перед отменой внесенных изменений 
    BeforeClose	Перед закрытием набора данных 
    BeforeEdit	Перед редактированием данных 
    Beforelnsert	Перед вставкой или добавлением строки 
    BeforeOpen	Перед открытием набора данных 
    OnCalcFields	Если вычисляемое поле требует переменной 
    OnDeleteError	В случае проблем с удалением записи 
    OnEditError	В случае проблем с редактированием записи 
    OnFilterRecor	Если включен оежим (Ьильтоаиии и набооу данных не( 

    430 IV. Темы повышенной сложности 

    Резюме 

    В этой главе вы узнали о четырех основных уровнях реализации бизнес-правил 
в приложениях Delphi: уровень типов данных, уровень компонентов, уровень 
TField и уровень TDataSet. Каждый из этих уровней упрощает использование 
последующих. Подбор правильного типа данных для поля сильно облегчает выбор 
подходящего для работы с ним компонента пользовательского интерфейса. 
Аналогично, если правильно определить свойства TField, то работа на уровне 
DataSet становится менее сложной. Процесс создания бизнес-правил здесь 
напоминает пирамиду: чем надежнее построены нижние уровни, тем легче строить 
верхние. Небрежность, допущенная на нижних уровнях, обернется трудностями при 
создании верхних, а также уменьшением их стабильности. Необходимо внимательно 
относиться к мелким особенностям бизнес-правил в приложении, поскольку даже 
ничтожная деталь может очень сильно повлиять на его производительность. 

    Что дальше... 

    В следующей главе рассказывается о создании в Delphi многоуровневых 
приложений с использованием вспомогательных объектов. Положенная в основу этих 
объектов технология MIDAS (Multi-tier Distributed Applications Services Suite 
— набор служб для многоуровневых распределенных приложений), позволяет выйти 
за рамки ограничений двухуровневой модели клиент/сервер и создавать приложения 
уровня предприятия. 

    Глава 21. Бизнес-правила в приложениях	431