Как правильно использовать элементы управления данными?

Question

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

Я разработал несколько приложений БД, в которых ради «удобной для пользователя политики» я сталкиваюсь со сложной сетью табличных событий (afterinsert, afteredit, after ... и beforeedit, beforeinsert, before ...). После этого отладка приложения была довольно неприятной.

Осознавая этот риск (позже другим приложением), я пытался избежать этой проблемы, поэтому я уделил повышенное внимание написанию кода, хорошо читаемого и всеобъемлющего. С самого начала казалось, что все в порядке, но, поскольку мне нужно было обработать некоторые элементы предварительной обработки перед отправкой, загрузкой данных и т. Д., Я снова столкнулся с теми же проблемами, «медленно и неизбежно». Иногда я все равно не мог использовать средства управления данными, и то, что вначале казалось «крутой» функцией DAControl, в конце превращалось в препятствие. Я должен был написать специальную подпрограмму для элементов управления, не связанных с данными, чтобы вести себя как данные. Тогда я спросил себя, с какой стати я должен использовать средства управления данными? Лучше ли найти архитектуру приложения на элементах управления, не связанных с данными? Конечно, для написания кода, защищенного от ошибок, требуется больше времени, но стоит ли оно того? Я не знаю ...

Я бывал со мной несколько раз, как сглазил: рай в начале, ад в конце ...

Я не знаю, если я использую неправильный метод для написания программы БД, есть ли стандартная общая практика, как действовать. Или это общая проблема для всех?

Спасибо за советы и ваш опыт

Answer 1

Я написал приложения, в которых использовались компоненты, поддерживающие данные, против компонентов стиля TTable, а также приложения, в которых использовались компоненты, не поддерживающие данные.

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

Использование TClientDataSet Мне не нужно заставлять структуру моего пользовательского интерфейса имитировать структуру моей базы данных.Он достаточно гибок, чтобы заполнять его данными из нескольких таблиц, а затем, когда вы применяете обновления обратно к базе данных, вы можете вручную добавлять / удалять / обновлять записи по своему усмотрению.

Answer 2

Рассматривали ли вы O / R mapper для Delphi, например tiOPF или hcOPF ?

Это отделит логику бизнес-домена от слоя базы данных. Для больших и унаследованных систем даже принято добавлять еще один слой, « Anti Corruption Layer », который защищает модель от изменений в дизайне базы данных.

Answer 3

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

Я вижу следующие преимущества:

1. У меня есть полный контроль над всеми вставками / обновлениями / публикациями / изменениями в базе данных.
2. Не нужно беспокоиться о том, что пользователь оставит запись в режиме обновления (потенциально блокируя других пользователей)
3. СделалЯ упоминаю полный контроль над всеми вставками / обновлениями / публикациями / изменениями?

Использовать таблицу в памяти так же просто, как:

dataset.sql.add('select a.field,b.field from a,b');
dataset.open;
inMemoryTable.loadfromdataset(dataset);
inMemoryTable.checkpoint;

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

Answer 4

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

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

Если вам нужно написать слишком много функций склеивания, возможно, проблема в шаблоне проектирования, а не в VCL.