Форум: "Прочее";
Текущий архив: 2018.02.18;
Скачать: [xml.tar.bz2];
ВнизИзменить модель работы с базами данных в Delphi Найти похожие ветки
← →
DayGaykin © (2016-08-08 11:11) [0]Добрый день.
Всем так или иначе известна модель работы с данными в VCL: DataSet---DataSource---Controls.
Если бы у вас была возможность изменить что-либо связанное с этой моделью, что бы вы изменили?
Спасибо.
P.S. Никогда не понимал, зачем нужен DataSource, но и с базами данных в delphi особенно не работал.
← →
Плохиш © (2016-08-08 12:39) [1]
> P.S. Никогда не понимал, зачем нужен DataSource
В документации всё подробно и с примерами описано.
← →
Игорь Шевченко © (2016-08-08 13:06) [2]
> но и с базами данных в delphi особенно не работал.
Тогда ты не поймешь ответов
← →
DayGaykin © (2016-08-08 13:18) [3]
> Игорь Шевченко © (08.08.16 13:06) [2]
Ваше мнение хотелось бы узнать особенно.
← →
Игорь Шевченко © (2016-08-08 14:38) [4]DayGaykin © (08.08.16 13:18) [3]
Я бы ничего не стал менять, меня устраивает текущая модель
← →
Игорь Шевченко © (2016-08-08 14:41) [5]Вот тут дискуссия на аналогичную тему
http://www.sql.ru/forum/1219112-a/kak-poluchit-spisok-vseh-data-control-ov-privyazannyh-k-dataset
← →
MsGuns © (2016-08-08 15:27) [6]Все зависит от прихоти разработчика.
Грубо говоря есть два противоположных подхода.
1. Минимальные трудозатраты (по крайней мере на этапе первичного проектирования)
Визуализация обмена данными с БД выполняется компонентами, связанными по принципу "кинул на форму-настроил". Самый типичный пример -
[Соединение] -> [БД] -> [Набор данных (запрос/таблица/представление)] -> [Источник данных] -> [DB-Aware Controls]
Делается быстро и работает часто вполне надежно. В простейших случаях.
Из преимуществ это все. Далее идут сплошные недостатки. Из главных: сложность "тонкого" управления, например, транзакциями и исключениями. Также к недостаткам можно отнести необходимость перенастройки компонент (и перекомпилляции всего проекта с дальнейшим редеплоем ) при малейших изменениях в бизнес-логике БД, "тормоза" на больших объемах.
2. Понимание концепции "движка" и сервера БД. Максимальное использование "прямых" компонент типа Command и DataSet, гибко настраиваемых "на лету". Кода больше, он сложнее, но такое приложение автоматически настраивается под "сервер", не загружает его длинными транзакциями и серверными курсорами, менее требовательно к ресурсам клиентского ПК и при этом много "реактивнее".
← →
Kerk © (2016-08-08 15:36) [7]Я бы выкинул датаконтролы как понятие. Должна быть возможность привязать любой контрол к датасету. Для этого пытались сделать биндинги, но как-то не пошло оно у эмбаркадеры.
← →
MsGuns © (2016-08-08 15:37) [8]В общем случае при выборе модели работы с БД надо отталкиваться от предметной области, квалификации и количества пользователей, пользовательской среды (ПК+ОС), а также поставленных задач
Например, для небольшой торговой фирмы вполне подойдет "быстрая" технология.
А вот для сложного промышленного предприятия, где номенклатура комплектующих и материалов исчисляется десятками тысяч позиций, мудреные технологические процессы изготовления, конструктивная сложность продукции и т.д. нужна "тонкая" модель, способная быстро и адекватно реагировать на множественные изменения в общей структуре производства и планирования.
← →
Игорь Шевченко © (2016-08-08 18:52) [9]Kerk © (08.08.16 15:36) [7]
Должна быть возможность привязать любой контрол к любому источнику данных, не обязательно к датасету. Я вот к стыду своему про LiveBindings не знаю ровным счетом ничего.
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2018.02.18;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.001 c