Размышления на тему: недостатки датасетов

Данный пост представляет из себя размышления на тему: недостатки TDataSet. Я предполагаю, что читатель знаком с тем, что TDataSet – это базовый класс для работы с наборами данных (НД). Так же я предполагаю, что читатель знаком с основами программирования приложений для работы с базами данных (БД).

Delphi предлагает такую схему работы с НД:

а) TDataSet – для работы с самим НД;

б) TDataSource – источник данных, используется для связи НД с визуальными компонентами;

в) связь компонент с НД (для отображения и редактирования) через DataSource.

Вроде всё красиво.

Самое простое – это создание формы для редактирования конкретной записи: каждый контрол на форме связывается с конкретным полем НД. Перед редактированием пользователь выбирает запись, а после редактирования – либо сохраняет изменения, либо отменяет. Работа с конкретной записью не вызывает нареканий.

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

  Bookmark := DataSet.Bookmark;
  DataSet.DisableControls;
  try
    // work with DataSet
  finally
    DataSet.Bookmark := Bookmark;
    DataSet.EnableControls;
  end;

DisableControls/EnableControls необходимо делать, чтобы контролы не реагировали на изменение текущей записи и не вызывали мерцания, Bookmark нужен, чтобы после работы с НД вернуться к той записи, с которой работал пользователь.

У DataSet’ов есть свойство – текущее состояние. Есть промежуточное состояние – dsBrowse, и много разных – запись редактрируется, ищется, и т.п. Причём переход из одного состояния в другой возможен только через dsBrowse. А это означает, что если НД открыт на редактирование, то поиск по этому же НД уже не возможен. Более того, если я работаю, например, с иерархической структурой, то открыв запись на редактирование, я не могу использовать этот же НД для указания родительской записи.

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

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

 

Описанные проблемы – это не панацея. Все указанные неприятности либо решаются обходными путями, либо их можно игнорировать: задержки копирования сегодня настолько незначительны, что простому пользователю не заметны; чтобы не писать DisableControls/EnableControls можно создать шаблон кода.

 

Самым главным неудобством в датасете для меня является понятие текущей (активной) записи. На мой взгляд, это понятие надо отнести к гриду (либо, возможно, к DataSource’у). Если бы так было сделано изначально, то мы (программисты) получили бы возможность прозрачной навигации по НД. А работа с конкретной записью – она ведь определяется пользователем: именно пользователь выбирает строку в таблице (или даже несколько (!) строк), программисту логично запросить у грида выделенную строку (список выделенных строк) и работать с ними.

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

 

Наличие этих недостатков привело к созданию собственных механизмов для работы с НД. Подробно я их пока описывать не буду, приведу только такой пример:

TableName['FieldName'].AsString[Row] := SomeValue;

Здесь: TableName – имя таблицы, FieldName – имя поля, Row – ссылка на запись в НД. Так выглядит обращение в наших библиотеках к полю в общем случае. А благодаря автогенерации кода, о которой я попробую рассказать попозже, такой же код мы давно уже пишем так:

TableName.FieldName[Row] := SomeValue;

 

Ну и на последок скажу, что изобретение своего велосипеда у нас зашло довольно далеко – написаны механизмы для работы с БД, отдельно обёртки над компонентом VirtualTreeView для визуализации данных в виде таблицы, и отдельно обёртки над обычными компонентами ввода данных типа TEdit, TCombobox и т.п. С одной стороны, много самописного кода – обо всём этом за один раз не рассказать. Но с другой стороны нам это даёт много бонусов, что в конечном итоге (и я в это верю) положительно отражается на пользовательских интерфейсах.