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

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

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

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

Мне случалось со мной несколько раз, например, сглаженный: рай в начале ад на конце...

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

Thanx для советов и ваших впечатлений

Ответы

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Преимущества, которые я вижу:

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

Использование таблицы in-memory так же просто, как:

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

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

Ответ 4

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

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