Добрый день.

Всем так или иначе известна модель работы с данными в VCL: DataSet---DataSource---Controls.

Если бы у вас была возможность изменить что-либо связанное с этой моделью, что бы вы изменили?
Спасибо.

P.S. Никогда не понимал, зачем нужен DataSource, но и с базами данных в delphi особенно не работал.

> P.S. Никогда не понимал, зачем нужен DataSource

В документации всё подробно и с примерами описано.

> но и с базами данных в delphi особенно не работал.


Тогда ты не поймешь ответов

> Игорь Шевченко ©   (08.08.16 13:06) [2]

Ваше мнение хотелось бы узнать особенно.

DayGaykin ©   (08.08.16 13:18) [3]

Я бы ничего не стал менять, меня устраивает текущая модель

Вот тут дискуссия на аналогичную тему
http://www.sql.ru/forum/1219112-a/kak-poluchit-spisok-vseh-data-control-ov-privyazannyh-k-dataset

Все зависит от прихоти разработчика.
Грубо говоря есть два противоположных подхода.

1. Минимальные трудозатраты (по крайней мере на этапе первичного проектирования)
Визуализация обмена данными с БД выполняется компонентами, связанными по принципу "кинул на форму-настроил". Самый типичный пример -
[Соединение] -> [БД] -> [Набор данных (запрос/таблица/представление)] -> [Источник данных] -> [DB-Aware Controls]
Делается быстро и работает часто вполне надежно. В простейших случаях.
Из преимуществ это все. Далее идут сплошные недостатки. Из главных: сложность "тонкого" управления, например, транзакциями и исключениями. Также к недостаткам можно отнести необходимость перенастройки компонент (и перекомпилляции всего проекта с дальнейшим редеплоем ) при малейших изменениях в бизнес-логике БД, "тормоза" на больших объемах.

2. Понимание концепции "движка" и сервера БД. Максимальное использование "прямых" компонент типа Command и DataSet, гибко настраиваемых "на лету". Кода больше, он сложнее, но такое приложение автоматически настраивается под "сервер", не загружает его длинными транзакциями и серверными курсорами, менее требовательно к ресурсам клиентского ПК и при этом много "реактивнее".

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

В общем случае при выборе модели работы с БД надо отталкиваться от предметной области, квалификации и количества пользователей, пользовательской среды (ПК+ОС), а также поставленных задач

Например, для небольшой торговой фирмы вполне подойдет "быстрая" технология.

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

Kerk ©   (08.08.16 15:36) [7]

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