Работа с наборами данных в Datamodule

Question

У меня есть DataModule, и я хочу, чтобы внутри него было много (> 50) наборов данных. Я планирую запрашивать данные из этих наборов данных с помощью функций и процедур.

Вопрос в том, что является лучшим способом организовать наборы данных в DataModule?

Я вижу три варианта:

1. Один дизайна-компонент время для каждого набора данных.
2. Один общий набор компонентов времени разработки для всех наборов данных. Текст команды SQL и другие свойства динамически устанавливаются внутри соответствующей функции или процедуры.
3. Отсутствие компонентов времени разработки. Каждый набор данных создается во время выполнения внутри соответствующей функции, затем он возвращает данные в эту функцию и уничтожается.

Как вы думаете, какой путь является лучшим? Или ничего выше? Существуют ли другие способы эффективной организации множества наборов данных внутри DataModule?

Answer 1

Я использовал следующие настройки в модуле данных:

1) компоненты времени разработки с времени разработки запросов для:

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

• наборов данных для повторных выборок (так обычно с параметрами)

Я дал им имена, ссылки на объекты, которые они ВОССТАНОВЛЕНИЕ/обновления. Очистить для отладки и для других людей.

2) Компоненты времени разработки без SQL для специальных поисков и обновлений, обычно только с общим именем QryLookup и QryUpdate. Я просто устанавливаю SQL во время выполнения и выполняю. Часто без источника данных и т. Д.

Answer 2

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

Answer 3

Это отличный выбор в зависимости от вашего проекта.

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

Вариант 2. Меньше кода для поддержки, но сложнее редактировать с длинными строками SQL !. Легкая отладка.

Вариант 3. Я думаю, что это очень похоже на вариант 2.